On Mon, Dec 11, 2006 at 04:13:06PM +0530, Maneesh Soni wrote:
> On Mon, Dec 04, 2006 at 11:06:41AM -0500, Alan Stern wrote:
> > On Mon, 4 Dec 2006, Maneesh Soni wrote:
> >
> > > hmm, I guess Greg has to say the final word. The question is either to
> > > fail
> > > the IO (-ENODEV) or fail the fi
On Mon, Dec 04, 2006 at 11:06:41AM -0500, Alan Stern wrote:
> On Mon, 4 Dec 2006, Maneesh Soni wrote:
>
> > hmm, I guess Greg has to say the final word. The question is either to fail
> > the IO (-ENODEV) or fail the file removal (-EBUSY). If we are not going to
> > fail the removal then your patc
On Mon, Dec 04, 2006 at 06:34:06PM +0530, Maneesh Soni wrote:
> On Mon, Dec 04, 2006 at 07:38:00AM +0100, Oliver Neukum wrote:
> > Am Montag, 4. Dezember 2006 05:43 schrieb Maneesh Soni:
> > > On Fri, Dec 01, 2006 at 11:43:06PM +0100, Oliver Neukum wrote:
> > > > Hi,
> > > >
> > > > Alan Stern has
Am Montag, 4. Dezember 2006 17:57 schrieb Alan Stern:
> I was referring to sysfs_remove_file(), not sysfs_open_file() -- I agree
> that getting rid of the check_perm() routine is good. But this isn't:
>
> > void sysfs_remove_file(struct kobject * kobj, const struct attribute *
> > attr)
> >
On Mon, 4 Dec 2006, Oliver Neukum wrote:
> > Also, Oliver, it looks like the latest version of your patch makes an
> > unnecessary change to sysfs_remove_file().
>
> Code like:
>
> int d(int a, int b)
> {
> return a + b;
> }
>
> int c(int a, int b)
> {
> return d(a, b);
> }
>
> is
Am Montag, 4. Dezember 2006 17:06 schrieb Alan Stern:
> On Mon, 4 Dec 2006, Maneesh Soni wrote:
>
> > hmm, I guess Greg has to say the final word. The question is either to fail
> > the IO (-ENODEV) or fail the file removal (-EBUSY). If we are not going to
> > fail the removal then your patch is t
On Mon, 4 Dec 2006, Maneesh Soni wrote:
> hmm, I guess Greg has to say the final word. The question is either to fail
> the IO (-ENODEV) or fail the file removal (-EBUSY). If we are not going to
> fail the removal then your patch is the way to go.
>
> Greg?
Oliver is right that we cannot allow d
Am Montag, 4. Dezember 2006 14:04 schrieb Maneesh Soni:
> > > Hi Oliver,
> > >
> > > Thanks for the explaining the patch but some description about the race
> > > would also help here. At the least the callpath to the race would be
> > > useful.
> > >
> > >
> > > Thanks
> > > Maneesh
> >
> > We h
On Mon, Dec 04, 2006 at 07:38:00AM +0100, Oliver Neukum wrote:
> Am Montag, 4. Dezember 2006 05:43 schrieb Maneesh Soni:
> > On Fri, Dec 01, 2006 at 11:43:06PM +0100, Oliver Neukum wrote:
> > > Hi,
> > >
> > > Alan Stern has discovered a race in sysfs, whereby driver callbacks could
> > > be
> > >
Am Montag, 4. Dezember 2006 05:43 schrieb Maneesh Soni:
> On Fri, Dec 01, 2006 at 11:43:06PM +0100, Oliver Neukum wrote:
> > Hi,
> >
> > Alan Stern has discovered a race in sysfs, whereby driver callbacks could be
> > called after sysfs_remove_file() has run. The attached patch should fix it.
> >
On Fri, Dec 01, 2006 at 11:43:06PM +0100, Oliver Neukum wrote:
> Hi,
>
> Alan Stern has discovered a race in sysfs, whereby driver callbacks could be
> called after sysfs_remove_file() has run. The attached patch should fix it.
>
> It introduces a new data structure acting as a collection of all
Hi,
Alan Stern has discovered a race in sysfs, whereby driver callbacks could be
called after sysfs_remove_file() has run. The attached patch should fix it.
It introduces a new data structure acting as a collection of all sysfs_buffers
associated with an attribute. Upon removal of an attribute th
12 matches
Mail list logo
