[PATCH] mtd: ubi: Fix race condition between ubi device creation and udev

Iosif Harutyunov iharutyunov at SonicWALL.com
Thu Jul 21 17:32:15 PDT 2016


> On Thu, Jul 21, 2016 at 4:07 AM, Iosif Harutyunov
> <iharutyunov at sonicwall.com> wrote:
> >
> > While implementing udev rules for UBI device I ran into the problem
> > when udev would ignore UBI rules I created to process attachment of
> > volume. Interestingly, when I trigger udev ubi subsystem "change" event
> manually after the attachment, rules would work just fine.
> >
> > I traced problem down to UBI sysfs processing, which turned out to be
> racing condition.
> > See patch below to address the problem.
> 
> The symptom is that /dev/ubiX_Y appeared, udev got a notification but
> reading sysfs attributes always failed with -ENODEV?
> 
> How did you debug this? Sounds like a painful issue to debug. ;-\

Yes it was somewhat tricky. I actually found and debugged the problem on
kernel 3.10, but when I isolated the issue, it became obvious that late
initialization of ubi_devices[] is the problem.

I instrumented vol_attribute_show attr() processing code with log messages and
found that when udev reads attributes from sysfs, it returns ENODEV after calling
ubi_get_device(vol->ubi->ubi_num) to obtain ubi descriptor from given device
number. This is where I found that ubi_devices  array element corresponding to
ubi number is not initialized, which brought me to the ubi_attach_mtd_dev()
function.

I am surprised that this hasn't been caught before, but most likely not all platform
implementations induce this racing condition between kernel and udev event
processing. I my case platform is Octeon MIPS64.

> 
> >
> > Signed-off-by: Iosif Harutyunov <iharutyunov at sonicwall.com>
> > ---
> > Once ubi is attached, make sure ubi_devices[] is initialized early
> > before being used in the dev_attribute_show().
> >
> > This is to prevent race condition between udev ubi rules processing
> > and ubi device creation, which manifests itself ignoring udev ATTR rules.
> >
> > ---
> >  drivers/mtd/ubi/build.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index
> > ef36182..e6117d7 100644
> > --- a/drivers/mtd/ubi/build.c
> > +++ b/drivers/mtd/ubi/build.c
> > @@ -986,6 +986,8 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int
> ubi_num,
> >                 goto out_free;
> >         }
> >
> > +       ubi_devices[ubi_num] = ubi;
> > +
> 
> Okay, the fix is to make sure that ubi_devices[ubi_num] is set before we init
> sysfs.
> Why do you add this before the autoresize code?
> I'd expect it right before uif_init().

You are right. I think I was just being paranoid to initialize ubi_devices as early
as possible after attachments is made in case if anybody else is using it.
Agree with you that it should be right before uif_init().

Iosif,_



More information about the linux-mtd mailing list