diff options
author | Maxim Levitsky <maximlevitsky@gmail.com> | 2010-10-15 17:20:43 +0200 |
---|---|---|
committer | David Woodhouse <David.Woodhouse@intel.com> | 2010-10-25 01:28:30 +0100 |
commit | 008c751ec78587dd9b48bb62d4b10d616554fea2 (patch) | |
tree | 1334d9fd01dee2c0c4151824bd42886bc66cecd4 /tools | |
parent | ebd71e3a4861849054751779ff5ccd3fb29a1e0a (diff) |
mtd: allow to unload the mtdtrans module if its block devices aren't open
Now it once again possible to remove mtdtrans module.
You still need to ensure that block devices of that module aren't mounted.
This is due to the fact that as long as a block device is open, it still exists,
therefore if we were to allow module removal, this block device might became used again.
This time in addition to code review, I also made the code
pass some torture tests like module reload in a loop + read in a loop +
card insert/removal all at same time.
The blktrans_open/blktrans_release don't take the mtd table lock because:
While device is added (that includes execution of add_mtd_blktrans_dev)
the lock is already taken
Now suppose the device will never be removed. In this case even if we have changes
in mtd table, the entry that we need will stay exactly the same. (Note that we don't
look at table at all, just following private pointer of block device).
Now suppose that someone tries to remove the mtd device.
This will be propagated to trans driver which _ought_ to call del_mtd_blktrans_dev
which will take the per device lock, release the mtd device and set trans->mtd = NULL.
>From this point on, following opens won't even be able to know anything about that mtd device
(which at that point is likely not to exist)
Also the same care is taken not to trip over NULL mtd pointer in blktrans_dev_release.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Tested-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions