On Fri, Mar 21, 2014 at 10:18:13AM -0500, Josh Hunt wrote:
> On Sun, Feb 16, 2014 at 8:38 PM, Banerjee, Debabrata
> wrote:
> > On 2/16/14, 7:41 PM, "Linus Torvalds"
> > wrote:
> >
> >>On Sun, Feb 16, 2014 at 4:19 PM, Banerjee, Debabrata
> >> wrote:
> >>>
> >>> No that can't be right, the prev val
On Sun, Feb 16, 2014 at 8:38 PM, Banerjee, Debabrata
wrote:
> On 2/16/14, 7:41 PM, "Linus Torvalds"
> wrote:
>
>>On Sun, Feb 16, 2014 at 4:19 PM, Banerjee, Debabrata
>> wrote:
>>>
>>> No that can't be right, the prev value after every loop is the
>>>msg->flags
>>> from the *last* line in the list
On 2/16/14, 7:41 PM, "Linus Torvalds"
wrote:
>On Sun, Feb 16, 2014 at 4:19 PM, Banerjee, Debabrata
> wrote:
>>
>> No that can't be right, the prev value after every loop is the
>>msg->flags
>> from the *last* line in the list, which has no relation to the *first*,
>>so
>> reusing it for the top o
On Mon, Feb 17, 2014 at 2:19 AM, Kay Sievers wrote:
> On Mon, Feb 17, 2014 at 1:57 AM, Linus Torvalds
> wrote:
>> On Sun, Feb 16, 2014 at 4:50 PM, Kay Sievers wrote:
>>>
>>> That should avoid the overflow, yes. I expect it will not print the
>>> first line with a prefix, which we probably should
On Mon, Feb 17, 2014 at 1:57 AM, Linus Torvalds
wrote:
> On Sun, Feb 16, 2014 at 4:50 PM, Kay Sievers wrote:
>>
>> That should avoid the overflow, yes. I expect it will not print the
>> first line with a prefix, which we probably should.?
>
> Well, it's not printing out the prefix, but it's also
On Sun, Feb 16, 2014 at 4:50 PM, Kay Sievers wrote:
>
> That should avoid the overflow, yes. I expect it will not print the
> first line with a prefix, which we probably should.?
Well, it's not printing out the prefix, but it's also not printing out
the whole first part of the line, so quite fran
On Mon, Feb 17, 2014 at 1:41 AM, Linus Torvalds
wrote:
> On Sun, Feb 16, 2014 at 4:19 PM, Banerjee, Debabrata
> wrote:
> The third loop does *not* start again from the first line! It
> *continues* from where the second loop ended. Which is exactly why
> clearing "prev" is *wrong*. Because the *l
On Sun, Feb 16, 2014 at 4:19 PM, Banerjee, Debabrata
wrote:
>
> No that can't be right, the prev value after every loop is the msg->flags
> from the *last* line in the list, which has no relation to the *first*, so
> reusing it for the top of the next loop is nonsense.
Please, Debabrata, humor me
On 2/16/14, 6:59 PM, "Linus Torvalds"
wrote:
>On Sun, Feb 16, 2014 at 3:23 PM, Banerjee, Debabrata
> wrote:
>>
>> The explanation is: the loops look identical but they are not. When a
>> record is printed first, its size can expand due to adding the prefix
>>and
>> timestamp. The second loop is c
On Sun, Feb 16, 2014 at 3:23 PM, Banerjee, Debabrata
wrote:
>
> The explanation is: the loops look identical but they are not. When a
> record is printed first, its size can expand due to adding the prefix and
> timestamp. The second loop is calculating len with the first line printed
> possibly c
On 2/16/14, 2:28 PM, "Linus Torvalds"
wrote:
>Why are *those* particular two "prev = msg->flags" incorrect, when
>every other case where we walk the messages they are required?
>
>The code/logic makes no sense. You remove the "prev = msg->flags" at
>line 1070, when the *identical* loop just above
On Sun, Feb 16, 2014 at 9:47 PM, Greg Kroah-Hartman
wrote:
> On Sun, Feb 16, 2014 at 11:28:36AM -0800, Linus Torvalds wrote:
>> Adding Kay and Greg, since the original code is from commit
>> 7ff9554bb578 ("printk: convert byte-buffer to variable-length record
>> buffer") and all the "prev" flag tw
On Sun, Feb 16, 2014 at 11:28:36AM -0800, Linus Torvalds wrote:
> Adding Kay and Greg, since the original code is from commit
> 7ff9554bb578 ("printk: convert byte-buffer to variable-length record
> buffer") and all the "prev" flag tweaks end up building on top of
> that.
>
> The whole "prev flags
Adding Kay and Greg, since the original code is from commit
7ff9554bb578 ("printk: convert byte-buffer to variable-length record
buffer") and all the "prev" flag tweaks end up building on top of
that.
The whole "prev flags" is messed up, and LOG_CONT is done very confusingly.
Why are *those* part
Found another buffer overflow in this code that was introduced by
e3756477aec028427fec767957c0d4b6cfb87208 trying to solve a related overflow.
strace still shows a problem:
syslog(0x3, 0x7fffd65375d0, 0x1000) = 4107
The first record output was in the middle of a LOG_CONT line:
15 matches
Mail list logo