nothing strange. adds a page size to the address, then zero out all address bits that are offsets within a page and leaves the higher bits (ie page number) intact. in effect selects the start address of the next page.
it'd be more "correct" to do (X + (PS-1)) & ~(PS-1)
this would return X (instead of the current X+PS) if X is already at the start of a page
but for this case, both results are equally valid
---------- Post added at 06:13 AM ---------- Previous post was at 06:09 AM ----------
maybe they didn't upstream?
---------- Post added at 06:14 AM ---------- Previous post was at 06:13 AM ----------
no. that's an important commit but the struct is only used in handle_init.
---------- Post added at 06:47 AM ---------- Previous post was at 06:14 AM ----------
so i'm looking at the disassembly code. its a bit of a mess due to heavy inlining and optimizations. plus not knowing the instructions, addressing modes nor calling conventions also slows me down.
i'm seeing something so far compatible with a compiler bug, but i need to see more code to confirm or disprove. unfortunately i'll have to leave it for later because this is not what i should be doing right now.
the problem i'm having is that your observations contradict this bug, so i want to make sure i understood you correctly. you said "I tried many other variations, with putting in a dummy buffer before the read buffer to prevent the overlap. But the conclusions of that were that even a dummy buffer much larger than the request buffers didn't stop the problem". how exactly did you do this? did you do something like this:
Code:
union {
__u8 request_buffer[MAX_REQUEST_SIZE];
struct {
__u8 dummy[...];
__u8 read_buffer[MAX_READ];
};
};
Code:
union {
__u8 request_buffer[MAX_REQUEST_SIZE];
__u8 dummy[...];
__u8 read_buffer[MAX_READ];
};
