Re: sendsyslog file race

On Mon, Mar 27, 2017 at 6:09 PM, Alexander Bluhm wrote: > On Mon, Mar 27, 2017 at 05:39:27PM +0200, Mateusz Guzik wrote: > > The previous patch replaced multiple reads of the global var with just > > one read and had the result stored in a local variable, which then is >

Re: sendsyslog file race

> On Mon, Mar 27, 2017 at 05:39:27PM +0200, Mateusz Guzik wrote: > > The previous patch replaced multiple reads of the global var with just > > one read and had the result stored in a local variable, which then is > > read multiple times. Even though the compiler ended up emitting one read > > of

Re: sendsyslog file race

On Mon, Mar 27, 2017 at 05:39:27PM +0200, Mateusz Guzik wrote: > The previous patch replaced multiple reads of the global var with just > one read and had the result stored in a local variable, which then is > read multiple times. Even though the compiler ended up emitting one read > of the

Re: sendsyslog file race

On Sun, Mar 26, 2017 at 10:04 PM, Alexander Bluhm wrote: > On Sun, Mar 26, 2017 at 05:00:12PM +0200, Mateusz Guzik wrote: > > The patch is somewhat incorrect, although from what I checked it happens > > to generate the expected outcome in terms of assembly (the global

Re: sendsyslog file race

On Sun, Mar 26, 2017 at 05:00:12PM +0200, Mateusz Guzik wrote: > The patch is somewhat incorrect, although from what I checked it happens > to generate the expected outcome in terms of assembly (the global pointer > read only once and then a local copy accessed several times). You either > need a

Re: sendsyslog file race

On Fri, Mar 24, 2017 at 4:56 PM, Alexander Bluhm wrote: > Hi, > > There is a race in dosendsyslog() which resulted in a crash on a > 5.9 system. sosend(syslogf->f_data, ...) was called with a NULL > pointer. So syslogf is not NULL, f_data is NULL and f_count is 1. > >