Zbyněk Burget napsal/wrote, On 12/05/09 20:22:
Tak nevim - zkusil jsem do kernelu prihodit
options PRINTF_BUFR_SIZE=128
prelozil jsem, zrestartoval jsem a hlasky do messages chodi uplne stejne
Pravdepodobnejsi je, ze moje analyza nebyla spravna, problem je jinde a
toto neni jeho resen
Dan Lukes napsal(a):
Ten, kdo PR uzavrel si mysli, ze resenim je pouzit
options PRINTF_BUFR_SIZE=N
Pak, kdyz dojde k prokladani, tak nebude prokladano po jednom znaku, ale
po N. Reklo by se - staci vzit dostatecne velke 'N' a je v podstate
vyreseno. Ano, jenze ten buffer se alokuje na zasobni
Dan Lukes napsal(a):
Zbyněk Burget napsal/wrote, On 11/29/09 21:49:
Je plny takovychhle zmatku:
Nov 29 21:44:09 charon kernel:
Nov 29 21:44:12 charon kernel: :
Nov 29 21:44:21 charon kernel: <<110>i1p10>fiwp:f w: 1030105 000C
oAucncte ptT CTP C1P7 629.2.4146..8190..252:84:7839 1502
0197.21.21
Vilem Kebrt napsal/wrote, On 11/30/09 23:31:
No jesli je ten buffer na zasobniku jak pise dan, mohlo by se mozna
jednat i o docela velky security leak ? Ale to teoretizuji...
To spis ne. Bavime se o bufferu, pres ktery probiha vypisovani ze
samotneho kernelu (vc. loadovanych modulu). Kod bezic
Ahoj,
Zbyněk Burget napsal(a):
Dan Lukes napsal(a):
> No, proc tam nabidnuty patch neni tam je vysvetleno - tato cast kodu se
vola i v kontextech kdy pouziti zamku (a tedy serializace jak jsem ji
popsal vcera) neni bezpecne pouzitelna.
To je sice hezke, ale pokud nekde neco dela nesmysly, bylo
Zbyněk Burget napsal/wrote, On 11/30/09 21:00:
resenim je pouzit
options PRINTF_BUFR_SIZE=N
Pak, kdyz dojde k prokladani, tak nebude prokladano po jednom znaku,
ale po N.
Jak velke to N je ted (kde to zjistim)?
Jak vyse receno (pokud nemas v konfiguraku uvedeno, vypisuje s epo jednom).
Co
Dan Lukes napsal(a):
> No, proc tam nabidnuty patch neni tam je vysvetleno - tato cast kodu se
vola i v kontextech kdy pouziti zamku (a tedy serializace jak jsem ji
popsal vcera) neni bezpecne pouzitelna.
To je sice hezke, ale pokud nekde neco dela nesmysly, bylo by dobre, aby
na to nekdo sed
Miroslav Prýmek napsal/wrote, On 11/30/09 08:58:
Taky jsem na to narazil. Je to tahle chyba:
http://www.freebsd.org/cgi/query-pr.cgi?pr=116310
Nevim, proc je oznacena jako closed, kdyz patch ve zdrojacich zjevne neni...
No, proc tam nabidnuty patch neni tam je vysvetleno - tato cast kodu se
v
On 29.11.2009, at 21:49, Zbyněk Burget wrote:
> Zdravim, kouknul jsem dnes do /var/messages a nechapu.
> Je plny takovychhle zmatku:
>
> Nov 29 21:44:09 charon kernel:
> Nov 29 21:44:12 charon kernel: :
> Nov 29 21:44:21 charon kernel: <<110>i1p10>fiwp:f w: 1030105 000C oAucncte
> ptT CTP C1P7
Zbyněk Burget napsal(a):
Zdravim, kouknul jsem dnes do /var/messages a nechapu.
Je plny takovychhle zmatku:
Nov 29 21:44:21 charon kernel: <<110>i1p10>fiwp:f w: 1030105 000C
oAucncte ptT CTP C1P7 629.2.4146..8190..252:84:7839 1502
0197.21.2146..21402..51:0427:8377 3o20u ti nv ivai ae me1m
po
Zbyněk Burget napsal/wrote, On 11/29/09 22:28:
Jediny takhle rozsypany je prave pouze messages.
No, a ja si myslim, ze z toho navic jen ty radky, ktere byly LOG_CONSOLE ...
do synchronizacnich primitiv okolo zapisu do LOG bufferu a zjistit,
kde jsou pouzite chybne (nebo nepouzite vubec). TO n
Dan Lukes napsal(a):
Zbyněk Burget napsal/wrote, On 11/29/09 21:49:
Je plny takovychhle zmatku:
Nov 29 21:44:09 charon kernel:
Nov 29 21:44:12 charon kernel: :
Nov 29 21:44:21 charon kernel: <<110>i1p10>fiwp:f w: 1030105 000C
oAucncte ptT CTP C1P7 629.2.4146..8190..252:84:7839 1502
0197.21.21
Zbyněk Burget napsal/wrote, On 11/29/09 21:49:
Je plny takovychhle zmatku:
Nov 29 21:44:09 charon kernel:
Nov 29 21:44:12 charon kernel: :
Nov 29 21:44:21 charon kernel: <<110>i1p10>fiwp:f w: 1030105 000C
oAucncte ptT CTP C1P7 629.2.4146..8190..252:84:7839 1502
0197.21.2146..21402..51:0427:837
13 matches
Mail list logo
