haproxy/include/proto/channel.h

813 lines
27 KiB
C
Raw Normal View History

/*
* include/proto/channel.h
* Channel management definitions, macros and inline functions.
*
* Copyright (C) 2000-2014 Willy Tarreau - w@1wt.eu
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation, version 2.1
* exclusively.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#ifndef _PROTO_CHANNEL_H
#define _PROTO_CHANNEL_H
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <common/config.h>
#include <common/chunk.h>
#include <common/ticks.h>
#include <common/time.h>
#include <types/channel.h>
#include <types/global.h>
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 22:22:06 +00:00
#include <types/stream.h>
#include <types/stream_interface.h>
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
#include <proto/task.h>
/* perform minimal intializations, report 0 in case of error, 1 if OK. */
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
int init_channel();
unsigned long long __channel_forward(struct channel *chn, unsigned long long bytes);
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* SI-to-channel functions working with buffers */
int ci_putblk(struct channel *chn, const char *str, int len);
struct buffer *ci_swpbuf(struct channel *chn, struct buffer *buf);
int ci_putchr(struct channel *chn, char c);
int ci_getline_nc(const struct channel *chn, char **blk1, size_t *len1, char **blk2, size_t *len2);
int ci_getblk_nc(const struct channel *chn, char **blk1, size_t *len1, char **blk2, size_t *len2);
int co_inject(struct channel *chn, const char *msg, int len);
int co_getline(const struct channel *chn, char *str, int len);
int co_getblk(const struct channel *chn, char *blk, int len, int offset);
int co_getline_nc(const struct channel *chn, const char **blk1, size_t *len1, const char **blk2, size_t *len2);
int co_getblk_nc(const struct channel *chn, const char **blk1, size_t *len1, const char **blk2, size_t *len2);
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 22:22:06 +00:00
/* returns a pointer to the stream the channel belongs to */
static inline struct stream *chn_strm(const struct channel *chn)
{
if (chn->flags & CF_ISRESP)
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 22:22:06 +00:00
return LIST_ELEM(chn, struct stream *, res);
else
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 22:22:06 +00:00
return LIST_ELEM(chn, struct stream *, req);
}
/* returns a pointer to the stream interface feeding the channel (producer) */
static inline struct stream_interface *chn_prod(const struct channel *chn)
{
if (chn->flags & CF_ISRESP)
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 22:22:06 +00:00
return &LIST_ELEM(chn, struct stream *, res)->si[1];
else
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 22:22:06 +00:00
return &LIST_ELEM(chn, struct stream *, req)->si[0];
}
/* returns a pointer to the stream interface consuming the channel (producer) */
static inline struct stream_interface *chn_cons(const struct channel *chn)
{
if (chn->flags & CF_ISRESP)
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 22:22:06 +00:00
return &LIST_ELEM(chn, struct stream *, res)->si[0];
else
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 22:22:06 +00:00
return &LIST_ELEM(chn, struct stream *, req)->si[1];
}
/* c_orig() : returns the pointer to the channel buffer's origin */
static inline char *c_orig(const struct channel *c)
{
return b_orig(c->buf);
}
/* c_size() : returns the size of the channel's buffer */
static inline size_t c_size(const struct channel *c)
{
return b_size(c->buf);
}
/* c_wrap() : returns the pointer to the channel buffer's wrapping point */
static inline char *c_wrap(const struct channel *c)
{
return b_wrap(c->buf);
}
/* c_data() : returns the amount of data in the channel's buffer */
static inline size_t c_data(const struct channel *c)
{
return b_data(c->buf);
}
/* c_room() : returns the room left in the channel's buffer */
static inline size_t c_room(const struct channel *c)
{
return b_size(c->buf) - b_data(c->buf);
}
/* c_empty() : returns a boolean indicating if the channel's buffer is empty */
static inline size_t c_empty(const struct channel *c)
{
return !c_data(c);
}
/* c_full() : returns a boolean indicating if the channel's buffer is full */
static inline size_t c_full(const struct channel *c)
{
return !c_room(c);
}
/* co_data() : returns the amount of output data in the channel's buffer */
static inline size_t co_data(const struct channel *c)
{
return c->buf->o;
}
/* ci_data() : returns the amount of input data in the channel's buffer */
static inline size_t ci_data(const struct channel *c)
{
return c->buf->i;
}
/* ci_next() : for an absolute pointer <p> or a relative offset <o> pointing to
* a valid location within channel <c>'s buffer, returns either the absolute
* pointer or the relative offset pointing to the next byte, which usually is
* at (p + 1) unless p reaches the wrapping point and wrapping is needed.
*/
static inline size_t ci_next_ofs(const struct channel *c, size_t o)
{
return b_next_ofs(c->buf, o);
}
static inline char *ci_next(const struct channel *c, const char *p)
{
return b_next(c->buf, p);
}
/* c_ptr() : returns a pointer to an offset relative to the beginning of the
* input data in the buffer. If instead the offset is negative, a pointer to
* existing output data is returned. The function only takes care of wrapping,
* it's up to the caller to ensure the offset is always within byte count
* bounds.
*/
static inline char *c_ptr(const struct channel *c, ssize_t ofs)
{
return b_peek(c->buf, co_data(c) + ofs);
}
/* c_adv() : advances the channel's buffer by <adv> bytes, which means that the
* buffer's pointer advances, and that as many bytes from in are transferred
* from in to out. The caller is responsible for ensuring that adv is always
* smaller than or equal to b->i.
*/
static inline void c_adv(struct channel *c, size_t adv)
{
struct buffer *b = c->buf;
b->p = c_ptr(c, adv);
b->i -= adv;
b->o += adv;
}
/* c_rew() : rewinds the channel's buffer by <adv> bytes, which means that the
* buffer's pointer goes backwards, and that as many bytes from out are moved
* to in. The caller is responsible for ensuring that adv is always smaller
* than or equal to b->o.
*/
static inline void c_rew(struct channel *c, size_t adv)
{
struct buffer *b = c->buf;
b->p = c_ptr(c, (int)-adv);
b->i += adv;
b->o -= adv;
}
/* c_realign_if_empty() : realign the channel's buffer if it's empty */
static inline void c_realign_if_empty(struct channel *chn)
{
b_realign_if_empty(chn->buf);
}
/* co_head() : returns a pointer to the beginning of output data in the buffer.
* The "__" variants don't support wrapping, "ofs" are relative to
* the buffer's origin.
*/
static inline size_t __co_head_ofs(const struct channel *c)
{
return __b_peek_ofs(c->buf, 0);
}
static inline char *__co_head(const struct channel *c)
{
return __b_peek(c->buf, 0);
}
static inline size_t co_head_ofs(const struct channel *c)
{
return b_peek_ofs(c->buf, 0);
}
static inline char *co_head(const struct channel *c)
{
return b_peek(c->buf, 0);
}
/* co_tail() : returns a pointer to the end of output data in the buffer.
* The "__" variants don't support wrapping, "ofs" are relative to
* the buffer's origin.
*/
static inline size_t __co_tail_ofs(const struct channel *c)
{
return __b_peek_ofs(c->buf, co_data(c));
}
static inline char *__co_tail(const struct channel *c)
{
return __b_peek(c->buf, co_data(c));
}
static inline size_t co_tail_ofs(const struct channel *c)
{
return b_peek_ofs(c->buf, co_data(c));
}
static inline char *co_tail(const struct channel *c)
{
return b_peek(c->buf, co_data(c));
}
/* ci_head() : returns a pointer to the beginning of input data in the buffer.
* The "__" variants don't support wrapping, "ofs" are relative to
* the buffer's origin.
*/
static inline size_t __ci_head_ofs(const struct channel *c)
{
return __b_peek_ofs(c->buf, co_data(c));
}
static inline char *__ci_head(const struct channel *c)
{
return __b_peek(c->buf, co_data(c));
}
static inline size_t ci_head_ofs(const struct channel *c)
{
return b_peek_ofs(c->buf, co_data(c));
}
static inline char *ci_head(const struct channel *c)
{
return b_peek(c->buf, co_data(c));
}
/* ci_tail() : returns a pointer to the end of input data in the buffer.
* The "__" variants don't support wrapping, "ofs" are relative to
* the buffer's origin.
*/
static inline size_t __ci_tail_ofs(const struct channel *c)
{
return __b_peek_ofs(c->buf, c_data(c));
}
static inline char *__ci_tail(const struct channel *c)
{
return __b_peek(c->buf, c_data(c));
}
static inline size_t ci_tail_ofs(const struct channel *c)
{
return b_peek_ofs(c->buf, c_data(c));
}
static inline char *ci_tail(const struct channel *c)
{
return b_peek(c->buf, c_data(c));
}
/* ci_stop() : returns the pointer to the byte following the end of input data
* in the channel buffer. It may be out of the buffer. It's used to
* compute lengths or stop pointers.
*/
static inline size_t __ci_stop_ofs(const struct channel *c)
{
return __b_stop_ofs(c->buf);
}
static inline const char *__ci_stop(const struct channel *c)
{
return __b_stop(c->buf);
}
static inline size_t ci_stop_ofs(const struct channel *c)
{
return b_stop_ofs(c->buf);
}
static inline const char *ci_stop(const struct channel *c)
{
return b_stop(c->buf);
}
/* Returns the amount of input data that can contiguously be read at once */
static inline size_t ci_contig_data(const struct channel *c)
{
return b_contig_data(c->buf, co_data(c));
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* Initialize all fields in the channel. */
static inline void channel_init(struct channel *chn)
{
chn->buf = &buf_empty;
chn->to_forward = 0;
chn->last_read = now_ms;
chn->xfer_small = chn->xfer_large = 0;
chn->total = 0;
chn->pipe = NULL;
chn->analysers = 0;
chn->flags = 0;
}
/* Schedule up to <bytes> more bytes to be forwarded via the channel without
* notifying the owner task. Any data pending in the buffer are scheduled to be
* sent as well, in the limit of the number of bytes to forward. This must be
* the only method to use to schedule bytes to be forwarded. If the requested
* number is too large, it is automatically adjusted. The number of bytes taken
* into account is returned. Directly touching ->to_forward will cause lockups
* when buf->o goes down to zero if nobody is ready to push the remaining data.
*/
static inline unsigned long long channel_forward(struct channel *chn, unsigned long long bytes)
{
/* hint: avoid comparisons on long long for the fast case, since if the
* length does not fit in an unsigned it, it will never be forwarded at
* once anyway.
*/
if (bytes <= ~0U) {
unsigned int bytes32 = bytes;
if (bytes32 <= chn->buf->i) {
/* OK this amount of bytes might be forwarded at once */
c_adv(chn, bytes32);
return bytes;
}
}
return __channel_forward(chn, bytes);
}
BUG/MEDIUM: channel: fix inconsistent handling of 4GB-1 transfers In 1.4-dev3, commit 31971e5 ("[MEDIUM] add support for infinite forwarding") made it possible to configure the lower layer to forward data indefinitely by setting the forward size to CHN_INFINITE_FORWARD (4GB-1). By then larger chunk sizes were not supported so there was no confusion in the usage of the function. Since 1.5 we support 64-bit content-lengths and chunk sizes and the function has grown to support 64-bit arguments, though it still limits a single pass to 32-bit quantities (what fit in the channel's to_forward field). The issue now becomes that a 4GB-1 content-length can be confused with infinite forwarding (in fact it's 4GB-1+what was already in the buffer). It causes a visible effect when transferring this exact size because the transfer rate is lower than with other sizes due in part to the disabling of the Nagle algorithm on the sendto() call. In theory with keep-alive it should prevent a second request from being processed after such a transfer, but since the analysers are still present, the forwarding analyser properly counts down the remaining size to transfer and ultimately the transaction gets correctly reset so there is no visible effect. Since the root cause of the issue is an API problem (lack of distinction between a real valid length and a magic value), this patch modifies the API to have a new dedicated function called channel_forward_forever() to program a permanent forwarding. The existing function __channel_forward() was modified to properly take care of the requested sizes and ensure it 1) never overflows and 2) never reaches CHN_INFINITE_FORWARD by accident. It is worth noting that the function used to have a bug causing a 2GB forward to be scheduled if it was called with less data than what is present in buf->i. Fortunately this bug couldn't be triggered with existing code. This fix should be backported to 1.6 and 1.5. While it also theorically affects 1.4, it's better not to backport it there, as the risk of breaking large object transfers due to significant API differences is high, compared to the fact that the largest supported objects (4GB-1) are just slower to transfer.
2016-05-04 12:05:58 +00:00
/* Forwards any input data and marks the channel for permanent forwarding */
static inline void channel_forward_forever(struct channel *chn)
{
c_adv(chn, chn->buf->i);
BUG/MEDIUM: channel: fix inconsistent handling of 4GB-1 transfers In 1.4-dev3, commit 31971e5 ("[MEDIUM] add support for infinite forwarding") made it possible to configure the lower layer to forward data indefinitely by setting the forward size to CHN_INFINITE_FORWARD (4GB-1). By then larger chunk sizes were not supported so there was no confusion in the usage of the function. Since 1.5 we support 64-bit content-lengths and chunk sizes and the function has grown to support 64-bit arguments, though it still limits a single pass to 32-bit quantities (what fit in the channel's to_forward field). The issue now becomes that a 4GB-1 content-length can be confused with infinite forwarding (in fact it's 4GB-1+what was already in the buffer). It causes a visible effect when transferring this exact size because the transfer rate is lower than with other sizes due in part to the disabling of the Nagle algorithm on the sendto() call. In theory with keep-alive it should prevent a second request from being processed after such a transfer, but since the analysers are still present, the forwarding analyser properly counts down the remaining size to transfer and ultimately the transaction gets correctly reset so there is no visible effect. Since the root cause of the issue is an API problem (lack of distinction between a real valid length and a magic value), this patch modifies the API to have a new dedicated function called channel_forward_forever() to program a permanent forwarding. The existing function __channel_forward() was modified to properly take care of the requested sizes and ensure it 1) never overflows and 2) never reaches CHN_INFINITE_FORWARD by accident. It is worth noting that the function used to have a bug causing a 2GB forward to be scheduled if it was called with less data than what is present in buf->i. Fortunately this bug couldn't be triggered with existing code. This fix should be backported to 1.6 and 1.5. While it also theorically affects 1.4, it's better not to backport it there, as the risk of breaking large object transfers due to significant API differences is high, compared to the fact that the largest supported objects (4GB-1) are just slower to transfer.
2016-05-04 12:05:58 +00:00
chn->to_forward = CHN_INFINITE_FORWARD;
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/*********************************************************************/
/* These functions are used to compute various channel content sizes */
/*********************************************************************/
/* Reports non-zero if the channel is empty, which means both its
* buffer and pipe are empty. The construct looks strange but is
* jump-less and much more efficient on both 32 and 64-bit than
* the boolean test.
*/
static inline unsigned int channel_is_empty(const struct channel *c)
{
return !(c->buf->o | (long)c->pipe);
}
/* Returns non-zero if the channel is rewritable, which means that the buffer
* it is attached to has at least <maxrewrite> bytes immediately available.
* This is used to decide when a request or response may be parsed when some
* data from a previous exchange might still be present.
BUG/MAJOR: http: always ensure response buffer has some room for a response Since 1.5-dev12 and commit 3bf1b2b8 (MAJOR: channel: stop relying on BF_FULL to take action), the HTTP parser switched to channel_full() instead of BF_FULL to decide whether a buffer had enough room to start parsing a request or response. The problem is that channel_full() intentionally ignores outgoing data, so a corner case exists where a large response might still be left in a response buffer with just a few bytes left (much less than the reserve), enough to accept a second response past the last data, but not enough to permit the HTTP processor to add some headers. Since all the processing relies on this space being available, we can get some random crashes when clients pipeline requests. The analysis of a core from haproxy configured with 20480 bytes buffers shows this : with enough "luck", when sending back the response for the first request, the client is slow, the TCP window is congested, the socket buffers are full, and haproxy's buffer fills up. We still have 20230 bytes of response data in a 20480 response buffer. The second request is sent to the server which returns 214 bytes which fit in the small 250 bytes left in this buffer. And the buffer arrangement makes it possible to escape all the controls in http_wait_for_response() : |<------ response buffer = 20480 bytes ------>| [ 2/2 | 3 | 4 | 1/2 ] ^ start of circular buffer 1/2 = beginning of previous response (18240) 2/2 = end of previous response (1990) 3 = current response (214) 4 = free space (36) - channel_full() returns false (20230 bytes are going to leave) - the response headers does not wrap at the end of the buffer - the remaining linear room after the headers is larger than the reserve, because it's the previous response which wraps : => response is processed Header rewriting causes it to reach 260 bytes, 10 bytes larger than what the buffer could hold. So all computations during header addition are wrong and lead to the corruption we've observed. All the conditions are very hard to meet (which explains why it took almost one year for this bug to show up) and are almost impossible to reproduce on purpose on a test platform. But the bug is clearly there. This issue was reported by Dinko Korunic who kindly devoted a lot of time to provide countless traces and cores, and to experiment with troubleshooting patches to knock the bug down. Thanks Dinko! No backport is needed, but all 1.5-dev versions between dev12 and dev18 included must be upgraded. A workaround consists in setting option forceclose to prevent pipelined requests from being processed.
2013-06-08 10:55:46 +00:00
*/
static inline int channel_is_rewritable(const struct channel *chn)
BUG/MAJOR: http: always ensure response buffer has some room for a response Since 1.5-dev12 and commit 3bf1b2b8 (MAJOR: channel: stop relying on BF_FULL to take action), the HTTP parser switched to channel_full() instead of BF_FULL to decide whether a buffer had enough room to start parsing a request or response. The problem is that channel_full() intentionally ignores outgoing data, so a corner case exists where a large response might still be left in a response buffer with just a few bytes left (much less than the reserve), enough to accept a second response past the last data, but not enough to permit the HTTP processor to add some headers. Since all the processing relies on this space being available, we can get some random crashes when clients pipeline requests. The analysis of a core from haproxy configured with 20480 bytes buffers shows this : with enough "luck", when sending back the response for the first request, the client is slow, the TCP window is congested, the socket buffers are full, and haproxy's buffer fills up. We still have 20230 bytes of response data in a 20480 response buffer. The second request is sent to the server which returns 214 bytes which fit in the small 250 bytes left in this buffer. And the buffer arrangement makes it possible to escape all the controls in http_wait_for_response() : |<------ response buffer = 20480 bytes ------>| [ 2/2 | 3 | 4 | 1/2 ] ^ start of circular buffer 1/2 = beginning of previous response (18240) 2/2 = end of previous response (1990) 3 = current response (214) 4 = free space (36) - channel_full() returns false (20230 bytes are going to leave) - the response headers does not wrap at the end of the buffer - the remaining linear room after the headers is larger than the reserve, because it's the previous response which wraps : => response is processed Header rewriting causes it to reach 260 bytes, 10 bytes larger than what the buffer could hold. So all computations during header addition are wrong and lead to the corruption we've observed. All the conditions are very hard to meet (which explains why it took almost one year for this bug to show up) and are almost impossible to reproduce on purpose on a test platform. But the bug is clearly there. This issue was reported by Dinko Korunic who kindly devoted a lot of time to provide countless traces and cores, and to experiment with troubleshooting patches to knock the bug down. Thanks Dinko! No backport is needed, but all 1.5-dev versions between dev12 and dev18 included must be upgraded. A workaround consists in setting option forceclose to prevent pipelined requests from being processed.
2013-06-08 10:55:46 +00:00
{
int rem = chn->buf->size;
rem -= chn->buf->o;
rem -= chn->buf->i;
rem -= global.tune.maxrewrite;
return rem >= 0;
}
/* Tells whether data are likely to leave the buffer. This is used to know when
* we can safely ignore the reserve since we know we cannot retry a connection.
* It returns zero if data are blocked, non-zero otherwise.
*/
static inline int channel_may_send(const struct channel *chn)
{
return chn_cons(chn)->state == SI_ST_EST;
}
/* Returns non-zero if the channel can still receive data. This is used to
BUG/MAJOR: http: always ensure response buffer has some room for a response Since 1.5-dev12 and commit 3bf1b2b8 (MAJOR: channel: stop relying on BF_FULL to take action), the HTTP parser switched to channel_full() instead of BF_FULL to decide whether a buffer had enough room to start parsing a request or response. The problem is that channel_full() intentionally ignores outgoing data, so a corner case exists where a large response might still be left in a response buffer with just a few bytes left (much less than the reserve), enough to accept a second response past the last data, but not enough to permit the HTTP processor to add some headers. Since all the processing relies on this space being available, we can get some random crashes when clients pipeline requests. The analysis of a core from haproxy configured with 20480 bytes buffers shows this : with enough "luck", when sending back the response for the first request, the client is slow, the TCP window is congested, the socket buffers are full, and haproxy's buffer fills up. We still have 20230 bytes of response data in a 20480 response buffer. The second request is sent to the server which returns 214 bytes which fit in the small 250 bytes left in this buffer. And the buffer arrangement makes it possible to escape all the controls in http_wait_for_response() : |<------ response buffer = 20480 bytes ------>| [ 2/2 | 3 | 4 | 1/2 ] ^ start of circular buffer 1/2 = beginning of previous response (18240) 2/2 = end of previous response (1990) 3 = current response (214) 4 = free space (36) - channel_full() returns false (20230 bytes are going to leave) - the response headers does not wrap at the end of the buffer - the remaining linear room after the headers is larger than the reserve, because it's the previous response which wraps : => response is processed Header rewriting causes it to reach 260 bytes, 10 bytes larger than what the buffer could hold. So all computations during header addition are wrong and lead to the corruption we've observed. All the conditions are very hard to meet (which explains why it took almost one year for this bug to show up) and are almost impossible to reproduce on purpose on a test platform. But the bug is clearly there. This issue was reported by Dinko Korunic who kindly devoted a lot of time to provide countless traces and cores, and to experiment with troubleshooting patches to knock the bug down. Thanks Dinko! No backport is needed, but all 1.5-dev versions between dev12 and dev18 included must be upgraded. A workaround consists in setting option forceclose to prevent pipelined requests from being processed.
2013-06-08 10:55:46 +00:00
* decide when to stop reading into a buffer when we want to ensure that we
* leave the reserve untouched after all pending outgoing data are forwarded.
* The reserved space is taken into account if ->to_forward indicates that an
* end of transfer is close to happen. Note that both ->buf->o and ->to_forward
* are considered as available since they're supposed to leave the buffer. The
* test is optimized to avoid as many operations as possible for the fast case
* and to be used as an "if" condition. Just like channel_recv_limit(), we
* never allow to overwrite the reserve until the output stream interface is
* connected, otherwise we could spin on a POST with http-send-name-header.
*/
static inline int channel_may_recv(const struct channel *chn)
{
int rem = chn->buf->size;
if (chn->buf == &buf_empty)
return 1;
rem -= chn->buf->o;
rem -= chn->buf->i;
if (!rem)
return 0; /* buffer already full */
if (rem > global.tune.maxrewrite)
return 1; /* reserve not yet reached */
if (!channel_may_send(chn))
return 0; /* don't touch reserve until we can send */
/* Now we know there's some room left in the reserve and we may
* forward. As long as i-to_fwd < size-maxrw, we may still
* receive. This is equivalent to i+maxrw-size < to_fwd,
* which is logical since i+maxrw-size is what overlaps with
* the reserve, and we want to ensure they're covered by scheduled
* forwards.
*/
rem = chn->buf->i + global.tune.maxrewrite - chn->buf->size;
return rem < 0 || (unsigned int)rem < chn->to_forward;
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* Returns true if the channel's input is already closed */
static inline int channel_input_closed(struct channel *chn)
{
return ((chn->flags & CF_SHUTR) != 0);
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* Returns true if the channel's output is already closed */
static inline int channel_output_closed(struct channel *chn)
{
return ((chn->flags & CF_SHUTW) != 0);
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* Check channel timeouts, and set the corresponding flags. The likely/unlikely
* have been optimized for fastest normal path. The read/write timeouts are not
* set if there was activity on the channel. That way, we don't have to update
* the timeout on every I/O. Note that the analyser timeout is always checked.
*/
static inline void channel_check_timeouts(struct channel *chn)
{
if (likely(!(chn->flags & (CF_SHUTR|CF_READ_TIMEOUT|CF_READ_ACTIVITY|CF_READ_NOEXP))) &&
unlikely(tick_is_expired(chn->rex, now_ms)))
chn->flags |= CF_READ_TIMEOUT;
BUG/MEDIUM: stream-int: Don't loss write's notifs when a stream is woken up When a write activity is reported on a channel, it is important to keep this information for the stream because it take part on the analyzers' triggering. When some data are written, the flag CF_WRITE_PARTIAL is set. It participates to the task's timeout updates and to the stream's waking. It is also used in CF_MASK_ANALYSER mask to trigger channels anaylzers. In the past, it was cleared by process_stream. Because of a bug (fixed in commit 95fad5ba4 ["BUG/MAJOR: stream-int: don't re-arm recv if send fails"]), It is now cleared before each send and in stream_int_notify. So it is possible to loss this information when process_stream is called, preventing analyzers to be called, and possibly leading to a stalled stream. Today, this happens in HTTP2 when you call the stat page or when you use the cache filter. In fact, this happens when the response is sent by an applet. In HTTP1, everything seems to work as expected. To fix the problem, we need to make the difference between the write activity reported to lower layers and the one reported to the stream. So the flag CF_WRITE_EVENT has been added to notify the stream of the write activity on a channel. It is set when a send succedded and reset by process_stream. It is also used in CF_MASK_ANALYSER. finally, it is checked in stream_int_notify to wake up a stream and in channel_check_timeouts. This bug is probably present in 1.7 but it seems to have no effect. So for now, no needs to backport it.
2017-11-09 08:36:43 +00:00
if (likely(!(chn->flags & (CF_SHUTW|CF_WRITE_TIMEOUT|CF_WRITE_ACTIVITY|CF_WRITE_EVENT))) &&
unlikely(tick_is_expired(chn->wex, now_ms)))
chn->flags |= CF_WRITE_TIMEOUT;
if (likely(!(chn->flags & CF_ANA_TIMEOUT)) &&
unlikely(tick_is_expired(chn->analyse_exp, now_ms)))
chn->flags |= CF_ANA_TIMEOUT;
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* Erase any content from channel <buf> and adjusts flags accordingly. Note
[MEDIUM] i/o: rework ->to_forward and ->send_max The way the buffers and stream interfaces handled ->to_forward was really not handy for multiple reasons. Now we've moved its control to the receive-side of the buffer, which is also responsible for keeping send_max up to date. This makes more sense as it now becomes possible to send some pre-formatted data followed by forwarded data. The following explanation has also been added to buffer.h to clarify the situation. Right now, tests show that the I/O is behaving extremely well. Some work will have to be done to adapt existing splice code though. /* Note about the buffer structure The buffer contains two length indicators, one to_forward counter and one send_max limit. First, it must be understood that the buffer is in fact split in two parts : - the visible data (->data, for ->l bytes) - the invisible data, typically in kernel buffers forwarded directly from the source stream sock to the destination stream sock (->splice_len bytes). Those are used only during forward. In order not to mix data streams, the producer may only feed the invisible data with data to forward, and only when the visible buffer is empty. The consumer may not always be able to feed the invisible buffer due to platform limitations (lack of kernel support). Conversely, the consumer must always take data from the invisible data first before ever considering visible data. There is no limit to the size of data to consume from the invisible buffer, as platform-specific implementations will rarely leave enough control on this. So any byte fed into the invisible buffer is expected to reach the destination file descriptor, by any means. However, it's the consumer's responsibility to ensure that the invisible data has been entirely consumed before consuming visible data. This must be reflected by ->splice_len. This is very important as this and only this can ensure strict ordering of data between buffers. The producer is responsible for decreasing ->to_forward and increasing ->send_max. The ->to_forward parameter indicates how many bytes may be fed into either data buffer without waking the parent up. The ->send_max parameter says how many bytes may be read from the visible buffer. Thus it may never exceed ->l. This parameter is updated by any buffer_write() as well as any data forwarded through the visible buffer. The consumer is responsible for decreasing ->send_max when it sends data from the visible buffer, and ->splice_len when it sends data from the invisible buffer. A real-world example consists in part in an HTTP response waiting in a buffer to be forwarded. We know the header length (300) and the amount of data to forward (content-length=9000). The buffer already contains 1000 bytes of data after the 300 bytes of headers. Thus the caller will set ->send_max to 300 indicating that it explicitly wants to send those data, and set ->to_forward to 9000 (content-length). This value must be normalised immediately after updating ->to_forward : since there are already 1300 bytes in the buffer, 300 of which are already counted in ->send_max, and that size is smaller than ->to_forward, we must update ->send_max to 1300 to flush the whole buffer, and reduce ->to_forward to 8000. After that, the producer may try to feed the additional data through the invisible buffer using a platform-specific method such as splice(). */
2009-01-07 23:09:41 +00:00
* that any spliced data is not affected since we may not have any access to
* it.
*/
static inline void channel_erase(struct channel *chn)
{
chn->to_forward = 0;
b_reset(chn->buf);
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* marks the channel as "shutdown" ASAP for reads */
static inline void channel_shutr_now(struct channel *chn)
[MAJOR] rework of the server FSM srv_state has been removed from HTTP state machines, and states have been split in either TCP states or analyzers. For instance, the TARPIT state has just become a simple analyzer. New flags have been added to the struct buffer to compensate this. The high-level stream processors sometimes need to force a disconnection without touching a file-descriptor (eg: report an error). But if they touched BF_SHUTW or BF_SHUTR, the file descriptor would not be closed. Thus, the two SHUT?_NOW flags have been added so that an application can request a forced close which the stream interface will be forced to obey. During this change, a new BF_HIJACK flag was added. It will be used for data generation, eg during a stats dump. It prevents the producer on a buffer from sending data into it. BF_SHUTR_NOW /* the producer must shut down for reads ASAP */ BF_SHUTW_NOW /* the consumer must shut down for writes ASAP */ BF_HIJACK /* the producer is temporarily replaced */ BF_SHUTW_NOW has precedence over BF_HIJACK. BF_HIJACK has precedence over BF_MAY_FORWARD (so that it does not need it). New functions buffer_shutr_now(), buffer_shutw_now(), buffer_abort() are provided to manipulate BF_SHUT* flags. A new type "stream_interface" has been added to describe both sides of a buffer. A stream interface has states and error reporting. The session now has two stream interfaces (one per side). Each buffer has stream_interface pointers to both consumer and producer sides. The server-side file descriptor has moved to its stream interface, so that even the buffer has access to it. process_srv() has been split into three parts : - tcp_get_connection() obtains a connection to the server - tcp_connection_failed() tests if a previously attempted connection has succeeded or not. - process_srv_data() only manages the data phase, and in this sense should be roughly equivalent to process_cli. Little code has been removed, and a lot of old code has been left in comments for now.
2008-10-19 05:30:41 +00:00
{
chn->flags |= CF_SHUTR_NOW;
[MAJOR] rework of the server FSM srv_state has been removed from HTTP state machines, and states have been split in either TCP states or analyzers. For instance, the TARPIT state has just become a simple analyzer. New flags have been added to the struct buffer to compensate this. The high-level stream processors sometimes need to force a disconnection without touching a file-descriptor (eg: report an error). But if they touched BF_SHUTW or BF_SHUTR, the file descriptor would not be closed. Thus, the two SHUT?_NOW flags have been added so that an application can request a forced close which the stream interface will be forced to obey. During this change, a new BF_HIJACK flag was added. It will be used for data generation, eg during a stats dump. It prevents the producer on a buffer from sending data into it. BF_SHUTR_NOW /* the producer must shut down for reads ASAP */ BF_SHUTW_NOW /* the consumer must shut down for writes ASAP */ BF_HIJACK /* the producer is temporarily replaced */ BF_SHUTW_NOW has precedence over BF_HIJACK. BF_HIJACK has precedence over BF_MAY_FORWARD (so that it does not need it). New functions buffer_shutr_now(), buffer_shutw_now(), buffer_abort() are provided to manipulate BF_SHUT* flags. A new type "stream_interface" has been added to describe both sides of a buffer. A stream interface has states and error reporting. The session now has two stream interfaces (one per side). Each buffer has stream_interface pointers to both consumer and producer sides. The server-side file descriptor has moved to its stream interface, so that even the buffer has access to it. process_srv() has been split into three parts : - tcp_get_connection() obtains a connection to the server - tcp_connection_failed() tests if a previously attempted connection has succeeded or not. - process_srv_data() only manages the data phase, and in this sense should be roughly equivalent to process_cli. Little code has been removed, and a lot of old code has been left in comments for now.
2008-10-19 05:30:41 +00:00
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* marks the channel as "shutdown" ASAP for writes */
static inline void channel_shutw_now(struct channel *chn)
[MAJOR] rework of the server FSM srv_state has been removed from HTTP state machines, and states have been split in either TCP states or analyzers. For instance, the TARPIT state has just become a simple analyzer. New flags have been added to the struct buffer to compensate this. The high-level stream processors sometimes need to force a disconnection without touching a file-descriptor (eg: report an error). But if they touched BF_SHUTW or BF_SHUTR, the file descriptor would not be closed. Thus, the two SHUT?_NOW flags have been added so that an application can request a forced close which the stream interface will be forced to obey. During this change, a new BF_HIJACK flag was added. It will be used for data generation, eg during a stats dump. It prevents the producer on a buffer from sending data into it. BF_SHUTR_NOW /* the producer must shut down for reads ASAP */ BF_SHUTW_NOW /* the consumer must shut down for writes ASAP */ BF_HIJACK /* the producer is temporarily replaced */ BF_SHUTW_NOW has precedence over BF_HIJACK. BF_HIJACK has precedence over BF_MAY_FORWARD (so that it does not need it). New functions buffer_shutr_now(), buffer_shutw_now(), buffer_abort() are provided to manipulate BF_SHUT* flags. A new type "stream_interface" has been added to describe both sides of a buffer. A stream interface has states and error reporting. The session now has two stream interfaces (one per side). Each buffer has stream_interface pointers to both consumer and producer sides. The server-side file descriptor has moved to its stream interface, so that even the buffer has access to it. process_srv() has been split into three parts : - tcp_get_connection() obtains a connection to the server - tcp_connection_failed() tests if a previously attempted connection has succeeded or not. - process_srv_data() only manages the data phase, and in this sense should be roughly equivalent to process_cli. Little code has been removed, and a lot of old code has been left in comments for now.
2008-10-19 05:30:41 +00:00
{
chn->flags |= CF_SHUTW_NOW;
[MAJOR] rework of the server FSM srv_state has been removed from HTTP state machines, and states have been split in either TCP states or analyzers. For instance, the TARPIT state has just become a simple analyzer. New flags have been added to the struct buffer to compensate this. The high-level stream processors sometimes need to force a disconnection without touching a file-descriptor (eg: report an error). But if they touched BF_SHUTW or BF_SHUTR, the file descriptor would not be closed. Thus, the two SHUT?_NOW flags have been added so that an application can request a forced close which the stream interface will be forced to obey. During this change, a new BF_HIJACK flag was added. It will be used for data generation, eg during a stats dump. It prevents the producer on a buffer from sending data into it. BF_SHUTR_NOW /* the producer must shut down for reads ASAP */ BF_SHUTW_NOW /* the consumer must shut down for writes ASAP */ BF_HIJACK /* the producer is temporarily replaced */ BF_SHUTW_NOW has precedence over BF_HIJACK. BF_HIJACK has precedence over BF_MAY_FORWARD (so that it does not need it). New functions buffer_shutr_now(), buffer_shutw_now(), buffer_abort() are provided to manipulate BF_SHUT* flags. A new type "stream_interface" has been added to describe both sides of a buffer. A stream interface has states and error reporting. The session now has two stream interfaces (one per side). Each buffer has stream_interface pointers to both consumer and producer sides. The server-side file descriptor has moved to its stream interface, so that even the buffer has access to it. process_srv() has been split into three parts : - tcp_get_connection() obtains a connection to the server - tcp_connection_failed() tests if a previously attempted connection has succeeded or not. - process_srv_data() only manages the data phase, and in this sense should be roughly equivalent to process_cli. Little code has been removed, and a lot of old code has been left in comments for now.
2008-10-19 05:30:41 +00:00
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* marks the channel as "shutdown" ASAP in both directions */
static inline void channel_abort(struct channel *chn)
[MAJOR] rework of the server FSM srv_state has been removed from HTTP state machines, and states have been split in either TCP states or analyzers. For instance, the TARPIT state has just become a simple analyzer. New flags have been added to the struct buffer to compensate this. The high-level stream processors sometimes need to force a disconnection without touching a file-descriptor (eg: report an error). But if they touched BF_SHUTW or BF_SHUTR, the file descriptor would not be closed. Thus, the two SHUT?_NOW flags have been added so that an application can request a forced close which the stream interface will be forced to obey. During this change, a new BF_HIJACK flag was added. It will be used for data generation, eg during a stats dump. It prevents the producer on a buffer from sending data into it. BF_SHUTR_NOW /* the producer must shut down for reads ASAP */ BF_SHUTW_NOW /* the consumer must shut down for writes ASAP */ BF_HIJACK /* the producer is temporarily replaced */ BF_SHUTW_NOW has precedence over BF_HIJACK. BF_HIJACK has precedence over BF_MAY_FORWARD (so that it does not need it). New functions buffer_shutr_now(), buffer_shutw_now(), buffer_abort() are provided to manipulate BF_SHUT* flags. A new type "stream_interface" has been added to describe both sides of a buffer. A stream interface has states and error reporting. The session now has two stream interfaces (one per side). Each buffer has stream_interface pointers to both consumer and producer sides. The server-side file descriptor has moved to its stream interface, so that even the buffer has access to it. process_srv() has been split into three parts : - tcp_get_connection() obtains a connection to the server - tcp_connection_failed() tests if a previously attempted connection has succeeded or not. - process_srv_data() only manages the data phase, and in this sense should be roughly equivalent to process_cli. Little code has been removed, and a lot of old code has been left in comments for now.
2008-10-19 05:30:41 +00:00
{
chn->flags |= CF_SHUTR_NOW | CF_SHUTW_NOW;
chn->flags &= ~CF_AUTO_CONNECT;
[MAJOR] rework of the server FSM srv_state has been removed from HTTP state machines, and states have been split in either TCP states or analyzers. For instance, the TARPIT state has just become a simple analyzer. New flags have been added to the struct buffer to compensate this. The high-level stream processors sometimes need to force a disconnection without touching a file-descriptor (eg: report an error). But if they touched BF_SHUTW or BF_SHUTR, the file descriptor would not be closed. Thus, the two SHUT?_NOW flags have been added so that an application can request a forced close which the stream interface will be forced to obey. During this change, a new BF_HIJACK flag was added. It will be used for data generation, eg during a stats dump. It prevents the producer on a buffer from sending data into it. BF_SHUTR_NOW /* the producer must shut down for reads ASAP */ BF_SHUTW_NOW /* the consumer must shut down for writes ASAP */ BF_HIJACK /* the producer is temporarily replaced */ BF_SHUTW_NOW has precedence over BF_HIJACK. BF_HIJACK has precedence over BF_MAY_FORWARD (so that it does not need it). New functions buffer_shutr_now(), buffer_shutw_now(), buffer_abort() are provided to manipulate BF_SHUT* flags. A new type "stream_interface" has been added to describe both sides of a buffer. A stream interface has states and error reporting. The session now has two stream interfaces (one per side). Each buffer has stream_interface pointers to both consumer and producer sides. The server-side file descriptor has moved to its stream interface, so that even the buffer has access to it. process_srv() has been split into three parts : - tcp_get_connection() obtains a connection to the server - tcp_connection_failed() tests if a previously attempted connection has succeeded or not. - process_srv_data() only manages the data phase, and in this sense should be roughly equivalent to process_cli. Little code has been removed, and a lot of old code has been left in comments for now.
2008-10-19 05:30:41 +00:00
}
/* allow the consumer to try to establish a new connection. */
static inline void channel_auto_connect(struct channel *chn)
{
chn->flags |= CF_AUTO_CONNECT;
}
/* prevent the consumer from trying to establish a new connection, and also
* disable auto shutdown forwarding.
*/
static inline void channel_dont_connect(struct channel *chn)
{
chn->flags &= ~(CF_AUTO_CONNECT|CF_AUTO_CLOSE);
}
/* allow the producer to forward shutdown requests */
static inline void channel_auto_close(struct channel *chn)
{
chn->flags |= CF_AUTO_CLOSE;
}
/* prevent the producer from forwarding shutdown requests */
static inline void channel_dont_close(struct channel *chn)
{
chn->flags &= ~CF_AUTO_CLOSE;
}
/* allow the producer to read / poll the input */
static inline void channel_auto_read(struct channel *chn)
{
chn->flags &= ~CF_DONT_READ;
}
/* prevent the producer from read / poll the input */
static inline void channel_dont_read(struct channel *chn)
{
chn->flags |= CF_DONT_READ;
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/*************************************************/
/* Buffer operations in the context of a channel */
/*************************************************/
/* Return the max number of bytes the buffer can contain so that once all the
BUG/MEDIUM: channel: fix miscalculation of available buffer space (3rd try) Latest fix 8a32106 ("BUG/MEDIUM: channel: fix miscalculation of available buffer space (2nd try)") did happen to fix some observable issues but not all of them in fact, some corner cases still remained and at least one user reported a busy loop that appeared possible, though not easily reproducible under experimental conditions. The remaining issue is that we still consider min(i, to_fwd) as the number of bytes in transit, but in fact <i> is not relevant here. Indeed, what matters is that we can read everything we want at once provided that at the end, <i> cannot be larger than <size-maxrw> (if it was not already). This is visible in two cases : - let's have i=o=max/2 and to_fwd=0. Then i+o >= max indicates that the buffer is already full, while it is not since once <o> is forwarded, some space remains. - when to_fwd is much larger than i, it's obvious that we can fill the buffer. The only relevant part in fact is o + to_fwd. to_fwd will ensure that at least this many bytes will be moved from <i> to <o> hence will leave the buffer, whatever the number of rounds it takes. Interestingly, the fix applied here ensures that channel_recv_max() will now equal (size - maxrw - i + to_fwd), which is indeed what remains available below maxrw after to_fwd bytes are forwarded from i to o and leave the buffer. Additionally, the latest fix made it possible to meet an integer overflow that was not caught by the range test when forwarding in TCP or tunnel mode due to to_forward being added to an existing value, causing the buffer size to be limited when it should not have been, resulting in 2 to 3 recv() calls when a single one was enough. The first one was limited to the unreserved buffer size, the second one to the size of the reserve minus 1, and the last one to the last byte. Eg with a 2kB buffer : recvfrom(22, "HTTP/1.1 200\r\nConnection: close\r"..., 1024, 0, NULL, NULL) = 1024 recvfrom(22, "23456789.123456789.123456789.123"..., 1023, 0, NULL, NULL) = 1023 recvfrom(22, "5", 1, 0, NULL, NULL) = 1 This bug is still present in 1.6 and 1.5 so the fix should be backported there.
2016-04-20 16:05:17 +00:00
* pending bytes are forwarded, the buffer still has global.tune.maxrewrite
* bytes free. The result sits between chn->size - maxrewrite and chn->size.
BUG/MEDIUM: channel: fix miscalculation of available buffer space (3rd try) Latest fix 8a32106 ("BUG/MEDIUM: channel: fix miscalculation of available buffer space (2nd try)") did happen to fix some observable issues but not all of them in fact, some corner cases still remained and at least one user reported a busy loop that appeared possible, though not easily reproducible under experimental conditions. The remaining issue is that we still consider min(i, to_fwd) as the number of bytes in transit, but in fact <i> is not relevant here. Indeed, what matters is that we can read everything we want at once provided that at the end, <i> cannot be larger than <size-maxrw> (if it was not already). This is visible in two cases : - let's have i=o=max/2 and to_fwd=0. Then i+o >= max indicates that the buffer is already full, while it is not since once <o> is forwarded, some space remains. - when to_fwd is much larger than i, it's obvious that we can fill the buffer. The only relevant part in fact is o + to_fwd. to_fwd will ensure that at least this many bytes will be moved from <i> to <o> hence will leave the buffer, whatever the number of rounds it takes. Interestingly, the fix applied here ensures that channel_recv_max() will now equal (size - maxrw - i + to_fwd), which is indeed what remains available below maxrw after to_fwd bytes are forwarded from i to o and leave the buffer. Additionally, the latest fix made it possible to meet an integer overflow that was not caught by the range test when forwarding in TCP or tunnel mode due to to_forward being added to an existing value, causing the buffer size to be limited when it should not have been, resulting in 2 to 3 recv() calls when a single one was enough. The first one was limited to the unreserved buffer size, the second one to the size of the reserve minus 1, and the last one to the last byte. Eg with a 2kB buffer : recvfrom(22, "HTTP/1.1 200\r\nConnection: close\r"..., 1024, 0, NULL, NULL) = 1024 recvfrom(22, "23456789.123456789.123456789.123"..., 1023, 0, NULL, NULL) = 1023 recvfrom(22, "5", 1, 0, NULL, NULL) = 1 This bug is still present in 1.6 and 1.5 so the fix should be backported there.
2016-04-20 16:05:17 +00:00
* It is important to mention that if buf->i is already larger than size-maxrw
* the condition above cannot be satisfied and the lowest size will be returned
* anyway. The principles are the following :
* 0) the empty buffer has a limit of zero
* 1) a non-connected buffer cannot touch the reserve
* 2) infinite forward can always fill the buffer since all data will leave
* 3) all output bytes are considered in transit since they're leaving
* 4) all input bytes covered by to_forward are considered in transit since
* they'll be converted to output bytes.
* 5) all input bytes not covered by to_forward as considered remaining
* 6) all bytes scheduled to be forwarded minus what is already in the input
* buffer will be in transit during future rounds.
* 7) 4+5+6 imply that the amount of input bytes (i) is irrelevant to the max
* usable length, only to_forward and output count. The difference is
* visible when to_forward > i.
* 8) the reserve may be covered up to the amount of bytes in transit since
* these bytes will only take temporary space.
*
BUG/MEDIUM: channel: fix miscalculation of available buffer space (3rd try) Latest fix 8a32106 ("BUG/MEDIUM: channel: fix miscalculation of available buffer space (2nd try)") did happen to fix some observable issues but not all of them in fact, some corner cases still remained and at least one user reported a busy loop that appeared possible, though not easily reproducible under experimental conditions. The remaining issue is that we still consider min(i, to_fwd) as the number of bytes in transit, but in fact <i> is not relevant here. Indeed, what matters is that we can read everything we want at once provided that at the end, <i> cannot be larger than <size-maxrw> (if it was not already). This is visible in two cases : - let's have i=o=max/2 and to_fwd=0. Then i+o >= max indicates that the buffer is already full, while it is not since once <o> is forwarded, some space remains. - when to_fwd is much larger than i, it's obvious that we can fill the buffer. The only relevant part in fact is o + to_fwd. to_fwd will ensure that at least this many bytes will be moved from <i> to <o> hence will leave the buffer, whatever the number of rounds it takes. Interestingly, the fix applied here ensures that channel_recv_max() will now equal (size - maxrw - i + to_fwd), which is indeed what remains available below maxrw after to_fwd bytes are forwarded from i to o and leave the buffer. Additionally, the latest fix made it possible to meet an integer overflow that was not caught by the range test when forwarding in TCP or tunnel mode due to to_forward being added to an existing value, causing the buffer size to be limited when it should not have been, resulting in 2 to 3 recv() calls when a single one was enough. The first one was limited to the unreserved buffer size, the second one to the size of the reserve minus 1, and the last one to the last byte. Eg with a 2kB buffer : recvfrom(22, "HTTP/1.1 200\r\nConnection: close\r"..., 1024, 0, NULL, NULL) = 1024 recvfrom(22, "23456789.123456789.123456789.123"..., 1023, 0, NULL, NULL) = 1023 recvfrom(22, "5", 1, 0, NULL, NULL) = 1 This bug is still present in 1.6 and 1.5 so the fix should be backported there.
2016-04-20 16:05:17 +00:00
* A typical buffer looks like this :
*
BUG/MEDIUM: channel: fix miscalculation of available buffer space (3rd try) Latest fix 8a32106 ("BUG/MEDIUM: channel: fix miscalculation of available buffer space (2nd try)") did happen to fix some observable issues but not all of them in fact, some corner cases still remained and at least one user reported a busy loop that appeared possible, though not easily reproducible under experimental conditions. The remaining issue is that we still consider min(i, to_fwd) as the number of bytes in transit, but in fact <i> is not relevant here. Indeed, what matters is that we can read everything we want at once provided that at the end, <i> cannot be larger than <size-maxrw> (if it was not already). This is visible in two cases : - let's have i=o=max/2 and to_fwd=0. Then i+o >= max indicates that the buffer is already full, while it is not since once <o> is forwarded, some space remains. - when to_fwd is much larger than i, it's obvious that we can fill the buffer. The only relevant part in fact is o + to_fwd. to_fwd will ensure that at least this many bytes will be moved from <i> to <o> hence will leave the buffer, whatever the number of rounds it takes. Interestingly, the fix applied here ensures that channel_recv_max() will now equal (size - maxrw - i + to_fwd), which is indeed what remains available below maxrw after to_fwd bytes are forwarded from i to o and leave the buffer. Additionally, the latest fix made it possible to meet an integer overflow that was not caught by the range test when forwarding in TCP or tunnel mode due to to_forward being added to an existing value, causing the buffer size to be limited when it should not have been, resulting in 2 to 3 recv() calls when a single one was enough. The first one was limited to the unreserved buffer size, the second one to the size of the reserve minus 1, and the last one to the last byte. Eg with a 2kB buffer : recvfrom(22, "HTTP/1.1 200\r\nConnection: close\r"..., 1024, 0, NULL, NULL) = 1024 recvfrom(22, "23456789.123456789.123456789.123"..., 1023, 0, NULL, NULL) = 1023 recvfrom(22, "5", 1, 0, NULL, NULL) = 1 This bug is still present in 1.6 and 1.5 so the fix should be backported there.
2016-04-20 16:05:17 +00:00
* <-------------- max_len ----------->
* <---- o ----><----- i -----> <--- 0..maxrewrite --->
* +------------+--------------+-------+----------------------+
* |////////////|\\\\\\\\\\\\\\|xxxxxxx| reserve |
* +------------+--------+-----+-------+----------------------+
* <- fwd -> <-avail->
*
* Or when to_forward > i :
*
* <-------------- max_len ----------->
* <---- o ----><----- i -----> <--- 0..maxrewrite --->
* +------------+--------------+-------+----------------------+
* |////////////|\\\\\\\\\\\\\\|xxxxxxx| reserve |
* +------------+--------+-----+-------+----------------------+
* <-avail->
* <------------------ fwd ---------------->
*
* - the amount of buffer bytes in transit is : min(i, fwd) + o
* - some scheduled bytes may be in transit (up to fwd - i)
* - the reserve is max(0, maxrewrite - transit)
* - the maximum usable buffer length is size - reserve.
* - the available space is max_len - i - o
*
* So the formula to compute the buffer's maximum length to protect the reserve
* when reading new data is :
*
* max = size - maxrewrite + min(maxrewrite, transit)
* = size - max(maxrewrite - transit, 0)
*
* But WARNING! The conditions might change during the transfer and it could
* very well happen that a buffer would contain more bytes than max_len due to
* i+o already walking over the reserve (eg: after a header rewrite), including
* i or o alone hitting the limit. So it is critical to always consider that
* bounds may have already been crossed and that available space may be negative
* for example. Due to this it is perfectly possible for this function to return
* a value that is lower than current i+o.
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
*/
static inline int channel_recv_limit(const struct channel *chn)
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
{
BUG/MAJOR: channel: fix miscalculation of available buffer space (4th try) Unfortunately, commit 169c470 ("BUG/MEDIUM: channel: fix miscalculation of available buffer space (3rd try)") was still not enough to completely address the issue. It fell into an integer comparison trap. Contrary to expectations, chn->to_forward may also have the sign bit set when forwarding regular data having a large content-length, resulting in an incomplete check of the result and of the reserve because the with to_forward very large, to_forward+o could become very small and also the reserve could become positive again and make channel_recv_limit() return a negative value. One way to reproduce this situation is to transfer a large file (> 2GB) with http-keep-alive or http-server-close, without splicing, and ensure that the server uses content-length instead of chunks. The transfer should stall very early after the first buffer has been transferred to the client. This fix now properly checks 1) for an overflow caused by summing o and to_forward, and 2) for o+to_forward being smaller or larger than maxrw before performing the subtract, so that all sensitive operations are properly performed on 33-bit arithmetics. The code was subjected again to a series of tests using inject+httpterm scanning a wide range of object sizes (+10MB after each new request) : $ printf "new page 1\nget 127.0.0.1:8002 / s=%%s0m\n" | \ inject64 -o 1 -u 1 -f /dev/stdin With previous fix, the transfer would suddenly stop when reaching 2GB : hits ^hits hits/s ^h/s bytes kB/s last errs tout htime sdht ptime 203 1 2 1 216816173354 2710202 3144892 0 0 685.0 0.0 685.0 205 2 2 2 219257283186 2706880 2441109 0 0 679.5 6.5 679.5 205 0 2 0 219257283186 2673836 0 0 0 0.0 0.0 0.0 205 0 2 0 219257283186 2641622 0 0 0 0.0 0.0 0.0 205 0 2 0 219257283186 2610174 0 0 0 0.0 0.0 0.0 Now it's fine even past 4 GB. Many thanks to Vedran Furac for reporting this issue early with a common access pattern helping to troubleshoot this. This fix must be backported to 1.6 and 1.5 where the commit above was already backported.
2016-05-03 15:46:24 +00:00
unsigned int transit;
int reserve;
/* return zero if empty */
reserve = chn->buf->size;
if (chn->buf == &buf_empty)
goto end;
/* return size - maxrewrite if we can't send */
reserve = global.tune.maxrewrite;
if (unlikely(!channel_may_send(chn)))
goto end;
BUG/MAJOR: channel: fix miscalculation of available buffer space (4th try) Unfortunately, commit 169c470 ("BUG/MEDIUM: channel: fix miscalculation of available buffer space (3rd try)") was still not enough to completely address the issue. It fell into an integer comparison trap. Contrary to expectations, chn->to_forward may also have the sign bit set when forwarding regular data having a large content-length, resulting in an incomplete check of the result and of the reserve because the with to_forward very large, to_forward+o could become very small and also the reserve could become positive again and make channel_recv_limit() return a negative value. One way to reproduce this situation is to transfer a large file (> 2GB) with http-keep-alive or http-server-close, without splicing, and ensure that the server uses content-length instead of chunks. The transfer should stall very early after the first buffer has been transferred to the client. This fix now properly checks 1) for an overflow caused by summing o and to_forward, and 2) for o+to_forward being smaller or larger than maxrw before performing the subtract, so that all sensitive operations are properly performed on 33-bit arithmetics. The code was subjected again to a series of tests using inject+httpterm scanning a wide range of object sizes (+10MB after each new request) : $ printf "new page 1\nget 127.0.0.1:8002 / s=%%s0m\n" | \ inject64 -o 1 -u 1 -f /dev/stdin With previous fix, the transfer would suddenly stop when reaching 2GB : hits ^hits hits/s ^h/s bytes kB/s last errs tout htime sdht ptime 203 1 2 1 216816173354 2710202 3144892 0 0 685.0 0.0 685.0 205 2 2 2 219257283186 2706880 2441109 0 0 679.5 6.5 679.5 205 0 2 0 219257283186 2673836 0 0 0 0.0 0.0 0.0 205 0 2 0 219257283186 2641622 0 0 0 0.0 0.0 0.0 205 0 2 0 219257283186 2610174 0 0 0 0.0 0.0 0.0 Now it's fine even past 4 GB. Many thanks to Vedran Furac for reporting this issue early with a common access pattern helping to troubleshoot this. This fix must be backported to 1.6 and 1.5 where the commit above was already backported.
2016-05-03 15:46:24 +00:00
/* We need to check what remains of the reserve after o and to_forward
* have been transmitted, but they can overflow together and they can
* cause an integer underflow in the comparison since both are unsigned
* while maxrewrite is signed.
* The code below has been verified for being a valid check for this :
* - if (o + to_forward) overflow => return size [ large enough ]
* - if o + to_forward >= maxrw => return size [ large enough ]
* - otherwise return size - (maxrw - (o + to_forward))
*/
BUG/MAJOR: channel: fix miscalculation of available buffer space (4th try) Unfortunately, commit 169c470 ("BUG/MEDIUM: channel: fix miscalculation of available buffer space (3rd try)") was still not enough to completely address the issue. It fell into an integer comparison trap. Contrary to expectations, chn->to_forward may also have the sign bit set when forwarding regular data having a large content-length, resulting in an incomplete check of the result and of the reserve because the with to_forward very large, to_forward+o could become very small and also the reserve could become positive again and make channel_recv_limit() return a negative value. One way to reproduce this situation is to transfer a large file (> 2GB) with http-keep-alive or http-server-close, without splicing, and ensure that the server uses content-length instead of chunks. The transfer should stall very early after the first buffer has been transferred to the client. This fix now properly checks 1) for an overflow caused by summing o and to_forward, and 2) for o+to_forward being smaller or larger than maxrw before performing the subtract, so that all sensitive operations are properly performed on 33-bit arithmetics. The code was subjected again to a series of tests using inject+httpterm scanning a wide range of object sizes (+10MB after each new request) : $ printf "new page 1\nget 127.0.0.1:8002 / s=%%s0m\n" | \ inject64 -o 1 -u 1 -f /dev/stdin With previous fix, the transfer would suddenly stop when reaching 2GB : hits ^hits hits/s ^h/s bytes kB/s last errs tout htime sdht ptime 203 1 2 1 216816173354 2710202 3144892 0 0 685.0 0.0 685.0 205 2 2 2 219257283186 2706880 2441109 0 0 679.5 6.5 679.5 205 0 2 0 219257283186 2673836 0 0 0 0.0 0.0 0.0 205 0 2 0 219257283186 2641622 0 0 0 0.0 0.0 0.0 205 0 2 0 219257283186 2610174 0 0 0 0.0 0.0 0.0 Now it's fine even past 4 GB. Many thanks to Vedran Furac for reporting this issue early with a common access pattern helping to troubleshoot this. This fix must be backported to 1.6 and 1.5 where the commit above was already backported.
2016-05-03 15:46:24 +00:00
transit = chn->buf->o + chn->to_forward;
reserve -= transit;
if (transit < chn->to_forward || // addition overflow
transit >= (unsigned)global.tune.maxrewrite) // enough transit data
BUG/MEDIUM: channel: fix miscalculation of available buffer space (3rd try) Latest fix 8a32106 ("BUG/MEDIUM: channel: fix miscalculation of available buffer space (2nd try)") did happen to fix some observable issues but not all of them in fact, some corner cases still remained and at least one user reported a busy loop that appeared possible, though not easily reproducible under experimental conditions. The remaining issue is that we still consider min(i, to_fwd) as the number of bytes in transit, but in fact <i> is not relevant here. Indeed, what matters is that we can read everything we want at once provided that at the end, <i> cannot be larger than <size-maxrw> (if it was not already). This is visible in two cases : - let's have i=o=max/2 and to_fwd=0. Then i+o >= max indicates that the buffer is already full, while it is not since once <o> is forwarded, some space remains. - when to_fwd is much larger than i, it's obvious that we can fill the buffer. The only relevant part in fact is o + to_fwd. to_fwd will ensure that at least this many bytes will be moved from <i> to <o> hence will leave the buffer, whatever the number of rounds it takes. Interestingly, the fix applied here ensures that channel_recv_max() will now equal (size - maxrw - i + to_fwd), which is indeed what remains available below maxrw after to_fwd bytes are forwarded from i to o and leave the buffer. Additionally, the latest fix made it possible to meet an integer overflow that was not caught by the range test when forwarding in TCP or tunnel mode due to to_forward being added to an existing value, causing the buffer size to be limited when it should not have been, resulting in 2 to 3 recv() calls when a single one was enough. The first one was limited to the unreserved buffer size, the second one to the size of the reserve minus 1, and the last one to the last byte. Eg with a 2kB buffer : recvfrom(22, "HTTP/1.1 200\r\nConnection: close\r"..., 1024, 0, NULL, NULL) = 1024 recvfrom(22, "23456789.123456789.123456789.123"..., 1023, 0, NULL, NULL) = 1023 recvfrom(22, "5", 1, 0, NULL, NULL) = 1 This bug is still present in 1.6 and 1.5 so the fix should be backported there.
2016-04-20 16:05:17 +00:00
return chn->buf->size;
end:
return chn->buf->size - reserve;
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
}
/* Returns non-zero if the channel's INPUT buffer's is considered full, which
* means that it holds at least as much INPUT data as (size - reserve). This
* also means that data that are scheduled for output are considered as potential
* free space, and that the reserved space is always considered as not usable.
* This information alone cannot be used as a general purpose free space indicator.
* However it accurately indicates that too many data were fed in the buffer
* for an analyzer for instance. See the channel_may_recv() function for a more
* generic function taking everything into account.
*/
static inline int channel_full(const struct channel *c, unsigned int reserve)
{
if (c->buf == &buf_empty)
return 0;
return (b_data(c->buf) - co_data(c) + reserve >= c_size(c));
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* Returns the amount of space available at the input of the buffer, taking the
* reserved space into account if ->to_forward indicates that an end of transfer
* is close to happen. The test is optimized to avoid as many operations as
* possible for the fast case.
*/
static inline int channel_recv_max(const struct channel *chn)
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
{
int ret;
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
ret = channel_recv_limit(chn) - chn->buf->i - chn->buf->o;
if (ret < 0)
ret = 0;
return ret;
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
}
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
/* Allocates a buffer for channel <chn>, but only if it's guaranteed that it's
* not the last available buffer or it's the response buffer. Unless the buffer
* is the response buffer, an extra control is made so that we always keep
* <tune.buffers.reserved> buffers available after this allocation. Returns 0 in
* case of failure, non-zero otherwise.
*
* If no buffer are available, the requester, represented by <wait> pointer,
* will be added in the list of objects waiting for an available buffer.
*/
static inline int channel_alloc_buffer(struct channel *chn, struct buffer_wait *wait)
{
int margin = 0;
if (!(chn->flags & CF_ISRESP))
margin = global.tune.reserved_bufs;
if (b_alloc_margin(&chn->buf, margin) != NULL)
return 1;
if (LIST_ISEMPTY(&wait->list)) {
HA_SPIN_LOCK(BUF_WQ_LOCK, &buffer_wq_lock);
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
LIST_ADDQ(&buffer_wq, &wait->list);
HA_SPIN_UNLOCK(BUF_WQ_LOCK, &buffer_wq_lock);
}
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
return 0;
}
/* Releases a possibly allocated buffer for channel <chn>. If it was not
* allocated, this function does nothing. Else the buffer is released and we try
* to wake up as many streams/applets as possible. */
static inline void channel_release_buffer(struct channel *chn, struct buffer_wait *wait)
{
if (c_size(chn) && c_empty(chn)) {
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
b_free(&chn->buf);
offer_buffers(wait->target, tasks_run_queue);
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 16:30:18 +00:00
}
}
/* Truncate any unread data in the channel's buffer, and disable forwarding.
* Outgoing data are left intact. This is mainly to be used to send error
* messages after existing data.
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
*/
static inline void channel_truncate(struct channel *chn)
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
{
if (!chn->buf->o)
return channel_erase(chn);
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
chn->to_forward = 0;
if (!chn->buf->i)
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
return;
chn->buf->i = 0;
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
}
/* This function realigns a possibly wrapping channel buffer so that the input
* part is contiguous and starts at the beginning of the buffer and the output
* part ends at the end of the buffer. This provides the best conditions since
* it allows the largest inputs to be processed at once and ensures that once
* the output data leaves, the whole buffer is available at once.
*/
static inline void channel_slow_realign(struct channel *chn, char *swap)
{
return b_slow_realign(chn->buf, swap, co_data(chn));
}
/*
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
* Advance the channel buffer's read pointer by <len> bytes. This is useful
* when data have been read directly from the buffer. It is illegal to call
* this function with <len> causing a wrapping at the end of the buffer. It's
* the caller's responsibility to ensure that <len> is never larger than
* chn->o. Channel flag WRITE_PARTIAL is set.
*/
static inline void co_skip(struct channel *chn, int len)
{
b_del(chn->buf, len);
c_realign_if_empty(chn);
/* notify that some data was written to the SI from the buffer */
BUG/MEDIUM: stream-int: Don't loss write's notifs when a stream is woken up When a write activity is reported on a channel, it is important to keep this information for the stream because it take part on the analyzers' triggering. When some data are written, the flag CF_WRITE_PARTIAL is set. It participates to the task's timeout updates and to the stream's waking. It is also used in CF_MASK_ANALYSER mask to trigger channels anaylzers. In the past, it was cleared by process_stream. Because of a bug (fixed in commit 95fad5ba4 ["BUG/MAJOR: stream-int: don't re-arm recv if send fails"]), It is now cleared before each send and in stream_int_notify. So it is possible to loss this information when process_stream is called, preventing analyzers to be called, and possibly leading to a stalled stream. Today, this happens in HTTP2 when you call the stat page or when you use the cache filter. In fact, this happens when the response is sent by an applet. In HTTP1, everything seems to work as expected. To fix the problem, we need to make the difference between the write activity reported to lower layers and the one reported to the stream. So the flag CF_WRITE_EVENT has been added to notify the stream of the write activity on a channel. It is set when a send succedded and reset by process_stream. It is also used in CF_MASK_ANALYSER. finally, it is checked in stream_int_notify to wake up a stream and in channel_check_timeouts. This bug is probably present in 1.7 but it seems to have no effect. So for now, no needs to backport it.
2017-11-09 08:36:43 +00:00
chn->flags |= CF_WRITE_PARTIAL | CF_WRITE_EVENT;
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* Tries to copy chunk <chunk> into the channel's buffer after length controls.
* The chn->o and to_forward pointers are updated. If the channel's input is
* closed, -2 is returned. If the block is too large for this buffer, -3 is
* returned. If there is not enough room left in the buffer, -1 is returned.
* Otherwise the number of bytes copied is returned (0 being a valid number).
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
* Channel flag READ_PARTIAL is updated if some data can be transferred. The
* chunk's length is updated with the number of bytes sent.
*/
static inline int ci_putchk(struct channel *chn, struct chunk *chunk)
{
int ret;
ret = ci_putblk(chn, chunk->str, chunk->len);
if (ret > 0)
chunk->len -= ret;
return ret;
}
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
/* Tries to copy string <str> at once into the channel's buffer after length
* controls. The chn->o and to_forward pointers are updated. If the channel's
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
* input is closed, -2 is returned. If the block is too large for this buffer,
* -3 is returned. If there is not enough room left in the buffer, -1 is
* returned. Otherwise the number of bytes copied is returned (0 being a valid
* number). Channel flag READ_PARTIAL is updated if some data can be
* transferred.
*/
static inline int ci_putstr(struct channel *chn, const char *str)
{
return ci_putblk(chn, str, strlen(str));
}
/*
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
* Return one char from the channel's buffer. If the buffer is empty and the
* channel is closed, return -2. If the buffer is just empty, return -1. The
* buffer's pointer is not advanced, it's up to the caller to call co_skip(buf,
CLEANUP: channel: use "channel" instead of "buffer" in function names This is a massive rename of most functions which should make use of the word "channel" instead of the word "buffer" in their names. In concerns the following ones (new names) : unsigned long long channel_forward(struct channel *buf, unsigned long long bytes); static inline void channel_init(struct channel *buf) static inline int channel_input_closed(struct channel *buf) static inline int channel_output_closed(struct channel *buf) static inline void channel_check_timeouts(struct channel *b) static inline void channel_erase(struct channel *buf) static inline void channel_shutr_now(struct channel *buf) static inline void channel_shutw_now(struct channel *buf) static inline void channel_abort(struct channel *buf) static inline void channel_stop_hijacker(struct channel *buf) static inline void channel_auto_connect(struct channel *buf) static inline void channel_dont_connect(struct channel *buf) static inline void channel_auto_close(struct channel *buf) static inline void channel_dont_close(struct channel *buf) static inline void channel_auto_read(struct channel *buf) static inline void channel_dont_read(struct channel *buf) unsigned long long channel_forward(struct channel *buf, unsigned long long bytes) Some functions provided by channel.[ch] have kept their "buffer" name because they are really designed to act on the buffer according to some information gathered from the channel. They have been moved together to the same place in the file for better readability but they were not changed at all. The "buffer" memory pool was also renamed "channel".
2012-08-27 22:06:31 +00:00
* 1) when it has consumed the char. Also note that this function respects the
* chn->o limit.
*/
static inline int co_getchr(struct channel *chn)
{
/* closed or empty + imminent close = -2; empty = -1 */
if (unlikely((chn->flags & CF_SHUTW) || channel_is_empty(chn))) {
if (chn->flags & (CF_SHUTW|CF_SHUTW_NOW))
return -2;
return -1;
}
return *buffer_wrap_sub(chn->buf, chn->buf->p - chn->buf->o);
}
#endif /* _PROTO_CHANNEL_H */
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/