28 Jun, 2016
1 commit
-
For block drivers that specify a parent device, convert them to use
device_add_disk().This conversion was done with the following semantic patch:
@@
struct gendisk *disk;
expression E;
@@- disk->driverfs_dev = E;
...
- add_disk(disk);
+ device_add_disk(E, disk);@@
struct gendisk *disk;
expression E1, E2;
@@- disk->driverfs_dev = E1;
...
E2 = disk;
...
- add_disk(E2);
+ device_add_disk(E1, E2);...plus some manual fixups for a few missed conversions.
Cc: Jens Axboe
Cc: Keith Busch
Cc: Michael S. Tsirkin
Cc: David Woodhouse
Cc: David S. Miller
Cc: James Bottomley
Cc: Ross Zwisler
Cc: Konrad Rzeszutek Wilk
Cc: Martin K. Petersen
Reviewed-by: Christoph Hellwig
Reviewed-by: Johannes Thumshirn
Signed-off-by: Dan Williams
08 Jun, 2016
2 commits
-
This adds a REQ_OP_FLUSH operation that is sent to request_fn
based drivers by the block layer's flush code, instead of
sending requests with the request->cmd_flags REQ_FLUSH bit set.Signed-off-by: Mike Christie
Reviewed-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
Signed-off-by: Jens Axboe -
The req operation REQ_OP is separated from the rq_flag_bits
definition. This converts the block layer drivers to
use req_op to get the op from the request struct.Signed-off-by: Mike Christie
Reviewed-by: Hannes Reinecke
Signed-off-by: Jens Axboe
13 Apr, 2016
1 commit
-
Signed-off-by: Jens Axboe
Reviewed-by: Christoph Hellwig
31 Oct, 2015
1 commit
-
Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.-> blktrans_open()
-> mutex_lock(&dev->lock);
-> mutex_lock(&mtd_table_mutex);-> del_mtd_device()
-> mutex_lock(&mtd_table_mutex);
-> blktrans_notify_remove() -> del_mtd_blktrans_dev()
-> mutex_lock(&dev->lock);This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired &dev->lock:if (mutex_trylock(&mtd_table_mutex)) {
mutex_unlock(&mtd_table_mutex);
BUG();
}So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so
we always acquire mtd_table_mutex first.Snippets of the lockdep output follow:
# modprobe -r m25p80
[ 53.419251]
[ 53.420838] ======================================================
[ 53.427300] [ INFO: possible circular locking dependency detected ]
[ 53.433865] 4.3.0-rc6 #96 Not tainted
[ 53.437686] -------------------------------------------------------
[ 53.444220] modprobe/372 is trying to acquire lock:
[ 53.449320] (&new->lock){+.+...}, at: [] del_mtd_blktrans_dev+0x80/0xdc
[ 53.457271]
[ 53.457271] but task is already holding lock:
[ 53.463372] (mtd_table_mutex){+.+.+.}, at: [] del_mtd_device+0x18/0x100
[ 53.471321]
[ 53.471321] which lock already depends on the new lock.
[ 53.471321]
[ 53.479856]
[ 53.479856] the existing dependency chain (in reverse order) is:
[ 53.487660]
-> #1 (mtd_table_mutex){+.+.+.}:
[ 53.492331] [] blktrans_open+0x34/0x1a4
[ 53.497879] [] __blkdev_get+0xc4/0x3b0
[ 53.503364] [] blkdev_get+0x108/0x320
[ 53.508743] [] do_dentry_open+0x218/0x314
[ 53.514496] [] path_openat+0x4c0/0xf9c
[ 53.519959] [] do_filp_open+0x5c/0xc0
[ 53.525336] [] do_sys_open+0xfc/0x1cc
[ 53.530716] [] ret_fast_syscall+0x0/0x1c
[ 53.536375]
-> #0 (&new->lock){+.+...}:
[ 53.540587] [] mutex_lock_nested+0x38/0x3cc
[ 53.546504] [] del_mtd_blktrans_dev+0x80/0xdc
[ 53.552606] [] blktrans_notify_remove+0x7c/0x84
[ 53.558891] [] del_mtd_device+0x74/0x100
[ 53.564544] [] del_mtd_partitions+0x80/0xc8
[ 53.570451] [] mtd_device_unregister+0x24/0x48
[ 53.576637] [] spi_drv_remove+0x1c/0x34
[ 53.582207] [] __device_release_driver+0x88/0x114
[ 53.588663] [] device_release_driver+0x20/0x2c
[ 53.594843] [] bus_remove_device+0xd8/0x108
[ 53.600748] [] device_del+0x10c/0x210
[ 53.606127] [] device_unregister+0xc/0x20
[ 53.611849] [] __unregister+0x10/0x20
[ 53.617211] [] device_for_each_child+0x50/0x7c
[ 53.623387] [] spi_unregister_master+0x58/0x8c
[ 53.629578] [] release_nodes+0x15c/0x1c8
[ 53.635223] [] __device_release_driver+0x90/0x114
[ 53.641689] [] driver_detach+0xb4/0xb8
[ 53.647147] [] bus_remove_driver+0x4c/0xa0
[ 53.652970] [] SyS_delete_module+0x11c/0x1e4
[ 53.658976] [] ret_fast_syscall+0x0/0x1c
[ 53.664621]
[ 53.664621] other info that might help us debug this:
[ 53.664621]
[ 53.672979] Possible unsafe locking scenario:
[ 53.672979]
[ 53.679169] CPU0 CPU1
[ 53.683900] ---- ----
[ 53.688633] lock(mtd_table_mutex);
[ 53.692383] lock(&new->lock);
[ 53.698306] lock(mtd_table_mutex);
[ 53.704658] lock(&new->lock);
[ 53.707946]
[ 53.707946] *** DEADLOCK ***Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount")
Reported-by: Felipe Balbi
Tested-by: Felipe Balbi
Signed-off-by: Brian Norris
Cc:
29 Sep, 2015
1 commit
-
In drivers/mtd/mtd_blkdevs.c:
406 set_capacity(gd, (new->size * tr->blksize) >> 9);
The type of new->size is unsigned long and the type of tr->blksize is int,
the result of 'new->size * tr->blksize' may exceed ULONG_MAX on 32bit
machines.I use nand chip MT29F32G08CBADBWP which is 4GB and the parameters passed
to kernel is 'mtdparts=gpmi-nand:-(user)', the whole nand chip will be
treated as a 4GB mtd partition. new->size is 0x800000 and tr->blksize is
0x200, 'new->size * tr->blksize' however is 0. This is what we do not want
to see.Using type cast u64 to fix the multiplication overflow issue.
Signed-off-by: Peng Fan
Cc: David Woodhouse
Signed-off-by: Brian Norris
03 Sep, 2015
1 commit
-
Pull core block updates from Jens Axboe:
"This first core part of the block IO changes contains:- Cleanup of the bio IO error signaling from Christoph. We used to
rely on the uptodate bit and passing around of an error, now we
store the error in the bio itself.- Improvement of the above from myself, by shrinking the bio size
down again to fit in two cachelines on x86-64.- Revert of the max_hw_sectors cap removal from a revision again,
from Jeff Moyer. This caused performance regressions in various
tests. Reinstate the limit, bump it to a more reasonable size
instead.- Make /sys/block//queue/discard_max_bytes writeable, by me.
Most devices have huge trim limits, which can cause nasty latencies
when deleting files. Enable the admin to configure the size down.
We will look into having a more sane default instead of UINT_MAX
sectors.- Improvement of the SGP gaps logic from Keith Busch.
- Enable the block core to handle arbitrarily sized bios, which
enables a nice simplification of bio_add_page() (which is an IO hot
path). From Kent.- Improvements to the partition io stats accounting, making it
faster. From Ming Lei.- Also from Ming Lei, a basic fixup for overflow of the sysfs pending
file in blk-mq, as well as a fix for a blk-mq timeout race
condition.- Ming Lin has been carrying Kents above mentioned patches forward
for a while, and testing them. Ming also did a few fixes around
that.- Sasha Levin found and fixed a use-after-free problem introduced by
the bio->bi_error changes from Christoph.- Small blk cgroup cleanup from Viresh Kumar"
* 'for-4.3/core' of git://git.kernel.dk/linux-block: (26 commits)
blk: Fix bio_io_vec index when checking bvec gaps
block: Replace SG_GAPS with new queue limits mask
block: bump BLK_DEF_MAX_SECTORS to 2560
Revert "block: remove artifical max_hw_sectors cap"
blk-mq: fix race between timeout and freeing request
blk-mq: fix buffer overflow when reading sysfs file of 'pending'
Documentation: update notes in biovecs about arbitrarily sized bios
block: remove bio_get_nr_vecs()
fs: use helper bio_add_page() instead of open coding on bi_io_vec
block: kill merge_bvec_fn() completely
md/raid5: get rid of bio_fits_rdev()
md/raid5: split bio for chunk_aligned_read
block: remove split code in blkdev_issue_{discard,write_same}
btrfs: remove bio splitting and merge_bvec_fn() calls
bcache: remove driver private bio splitting code
block: simplify bio_add_page()
block: make generic_make_request handle arbitrarily sized bios
blk-cgroup: Drop unlikely before IS_ERR(_OR_NULL)
block: don't access bio->bi_error after bio_put()
block: shrink struct bio down to 2 cache lines again
...
26 Aug, 2015
1 commit
-
With gcc 5.1 I get:
warning: switch condition has boolean value [-Wswitch-bool]Signed-off-by: Tomer Barletz
Signed-off-by: Brian Norris
17 Jul, 2015
1 commit
-
Some drivers use it now, others just set the limits field manually.
But in preparation for splitting this into a hard and soft limit,
ensure that they all call the proper function for setting the hw
limit for discards.Reviewed-by: Jeff Moyer
Signed-off-by: Jens Axboe
22 May, 2015
1 commit
-
In commit 50183936254b ("mtd: blktrans: change blktrans_getgeo return
value") we fixed the problem that ioctl(HDIO_GETGEO) might return 0
(success) for mtdblock devices which did not implement the feature and
would leave a blank (zero) result.But now, let's get the error code right. Other code paths on this ioctl
tend to use -ENOTTY to notify the user that the ioctl() is not supported
for the device, so let's use that instead of -EOPNOTSUPP.Suggested-by: Richard Weinberger
Signed-off-by: Brian Norris
21 May, 2015
1 commit
-
Modify function blktrans_getgeo()'s return value to -EOPNOTSUPP when
dev->tr->getgeo == NULL.We shouldn't make the return value to 0 when dev->tr->getgeo == NULL,
because the function blktrans_getgeo() has an output value "hd_geometry"
which is usually used by some application, if returns 0 (i.e.,
"success"), it will make some application get the wrong information.Signed-off-by: Wenlin Kang
Signed-off-by: Brian Norris
13 May, 2015
1 commit
-
On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to
mtd->usecount were done without taking mtd_table_mutex.
kernel: Call Trace:
kernel: [] __put_mtd_device+0x20/0x50
kernel: [] blktrans_release+0x8c/0xd8
kernel: [] __blkdev_put+0x1a8/0x200
kernel: [] blkdev_close+0x1c/0x30
kernel: [] __fput+0xac/0x250
kernel: [] task_work_run+0xd8/0x120
kernel: [] work_notifysig+0x10/0x18
kernel:
kernel:
Code: 2442ffff ac8202d8 000217fe dc820128 10400003
00000000 0040f809 00000000
kernel: ---[ end trace 080fbb4579b47a73 ]---Fixed by taking the mutex in blktrans_open and blktrans_release.
Note that this locking is already suggested in
include/linux/mtd/blktrans.h:struct mtd_blktrans_ops {
...
/* Called with mtd_table_mutex held; no race with add/remove */
int (*open)(struct mtd_blktrans_dev *dev);
void (*release)(struct mtd_blktrans_dev *dev);
...
};But we weren't following it.
Originally reported by (and patched by) Zhang and Giuseppe,
independently. Improved and rewritten.Cc: stable@vger.kernel.org
Reported-by: Zhang Xingcai
Reported-by: Giuseppe Cantavenera
Tested-by: Giuseppe Cantavenera
Acked-by: Alexander Sverdlin
Signed-off-by: Brian Norris
12 Mar, 2015
1 commit
-
The only exit (break) from the preceding loop is nested within a
condition which yields req == NULL. This code is dead.Coverity CID #752669
Signed-off-by: Brian Norris
05 Oct, 2014
1 commit
-
Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set
QUEUE_FLAG_NONROT.Historically, all block devices have automatically made entropy
contributions. But as previously stated in commit e2e1a148 ("block: add
sysfs knob for turning off disk entropy contributions"):
- On SSD disks, the completion times aren't as random as they
are for rotational drives. So it's questionable whether they
should contribute to the random pool in the first place.
- Calling add_disk_randomness() has a lot of overhead.There are more reliable sources for randomness than non-rotational block
devices. From a security perspective it is better to err on the side of
caution than to allow entropy contributions from unreliable "random"
sources.Signed-off-by: Mike Snitzer
Signed-off-by: Jens Axboe
11 Jun, 2014
1 commit
-
Pull MTD updates from Brian Norris:
- refactor m25p80.c driver for use as a general SPI NOR framework for
other drivers which may speak to SPI NOR flash without providing full
SPI support (i.e., not part of drivers/spi/)
- new Freescale QuadSPI driver (utilizing new SPI NOR framework)
- updates for the STMicro "FSM" SPI NOR driver
- fix sync/flush behavior on mtd_blkdevs
- fixup subpage write support on a few NAND drivers
- correct the MTD OOB test for odd-sized OOB areas
- add BCH-16 support for OMAP NAND
- fix warnings and trivial refactoring
- utilize new ECC DT bindings in pxa3xx NAND driver
- new LPDDR NVM driver
- address a few assorted bugs caught by Coverity
- add new imx6sx support for GPMI NAND
- use a bounce buffer for NAND when non-DMA-able buffers are used* tag 'for-linus-20140610' of git://git.infradead.org/linux-mtd: (77 commits)
mtd: gpmi: add gpmi support for imx6sx
mtd: maps: remove check for CONFIG_MTD_SUPERH_RESERVE
mtd: bf5xx_nand: use the managed version of kzalloc
mtd: pxa3xx_nand: make the driver work on big-endian systems
mtd: nand: omap: fix omap_calculate_ecc_bch() for-loop error
mtd: nand: r852: correct write_buf loop bounds
mtd: nand_bbt: handle error case for nand_create_badblock_pattern()
mtd: nand_bbt: remove unused variable
mtd: maps: sc520cdp: fix warnings
mtd: slram: fix unused variable warning
mtd: pfow: remove unused variable
mtd: lpddr: fix Kconfig dependency, for I/O accessors
mtd: nand: pxa3xx: Add supported ECC strength and step size to the DT binding
mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling
mtd: nand: Warn the user if the selected ECC strength is too weak
mtd: nand: omap: Documentation: How to select correct ECC scheme for your device ?
mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
mtd: nand: omap: add support for BCH16_ECC - ELM driver updates
mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates
...
16 Apr, 2014
2 commits
-
mtd_blkdevs is device with volatile cache (writeback buffer), so it should support
REQ_FLUSH to do explicit flush.Without this patch 'sync' does not guarantee that writeback buffer will be flushed
on disk in case of power off, e.g.:$ cp some_file /mnt
$ sync### POWER OFF
In case of this sequence writeback buffer will not be flushed on disk.
This patch fixes this behaviour and explicitly reports to block layer that flush
requests are being supported.Signed-off-by: Roman Peniaev
Cc: David Woodhouse
Cc: linux-mtd@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brian Norris -
This was used in the olden days, back when onions were proper
yellow. Basically it mapped to the current buffer to be
transferred. With highmem being added more than a decade ago,
most drivers map pages out of a bio, and rq->buffer isn't
pointing at anything valid.Convert old style drivers to just use bio_data().
For the discard payload use case, just reference the page
in the bio.Signed-off-by: Jens Axboe
11 Mar, 2014
1 commit
-
None of these files are actually using any __init type directives
and hence don't need to include . Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.Cc: David Woodhouse
Cc: Brian Norris
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Paul Gortmaker
[Brian: dropped one incorrect hunk]
Signed-off-by: Brian Norris
07 May, 2013
1 commit
-
The value passed is 0 in all but "it can never happen" cases (and those
only in a couple of drivers) *and* it would've been lost on the way
out anyway, even if something tried to pass something meaningful.
Just don't bother.Signed-off-by: Al Viro
06 May, 2013
1 commit
-
Both existing instances always return 0 and even if they didn't,
the value would be lost on the way out. Just don't bother...Signed-off-by: Al Viro
21 Nov, 2012
2 commits
-
By replacing a kthread with a workqueue, the code is now a bit clearer.
There's also a slight reduction of code size (numbers apply for x86):
Before:
text data bss dec hex filename
3248 36 0 3284 cd4 drivers/mtd/mtd_blkdevs.oAfter:
text data bss dec hex filename
3150 36 0 3186 c72 drivers/mtd/mtd_blkdevs.oDue to lack of real hardware, tests have been performed on an emulated
environment with mtdswap and mtdblock over nandsim devices.
Some real testing should be done, before merging this patch.Signed-off-by: Ezequiel Garcia
Signed-off-by: Artem Bityutskiy -
struct mtd_blktrans_ops is a type, and mtd_blktrans_ops is a variable.
To improve code clarity it's better to not use the same names,
so we just change the latter.Signed-off-by: Ezequiel Garcia
Signed-off-by: Artem Bityutskiy
27 Mar, 2012
1 commit
-
Because it is useless to call it if the device is opened in R/O mode, and also
harmful: on CFI NOR flash it may block for long time waiting for erase
operations to complete is another partition with a R/W file-system on this
chip.Artem Bityutskiy: write commit message, amend the patch to match the latest
tree (we use mtd_sync(), not mtd->sync() nowadays).Signed-off-by: Alexander Stein
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
10 Jan, 2012
1 commit
-
Some error paths in mtd_blkdevs were fixed in the following commit:
commit 94735ec4044a6d318b83ad3c5794e931ed168d10
mtd: mtd_blkdevs: fix error path in blktrans_openBut on these error paths, the block device's `dev->open' count is
already incremented before we check for errors. This meant that, while
the error path was handled correctly on the first time through
blktrans_open(), the device is erroneously considered already open on
the second time through.This problem can be seen, for instance, when a UBI volume is
simultaneously mounted as a UBIFS partition and read through its
corresponding gluebi mtdblockX device. This results in blktrans_open()
passing its error checks (with `dev->open > 0') without actually having
a handle on the device. Here's a summarized log of the actions and
results with nandsim:# modprobe nandsim
# modprobe mtdblock
# modprobe gluebi
# modprobe ubifs
# ubiattach /dev/ubi_ctrl -m 0
...
# ubimkvol /dev/ubi0 -N test -s 16MiB
...
# mount -t ubifs ubi0:test /mnt
# ls /dev/mtdblock*
/dev/mtdblock0 /dev/mtdblock1
# cat /dev/mtdblock1 > /dev/null
cat: can't open '/dev/mtdblock4': Device or resource busy
# cat /dev/mtdblock1 > /dev/nullCPU 0 Unable to handle kernel paging request at virtual address
fffffff0, epc == 8031536c, ra == 8031f280
Oops[#1]:
...
Call Trace:
[] ubi_leb_read+0x14/0x164
[] gluebi_read+0xf0/0x148
[] mtdblock_readsect+0x64/0x198
[] mtd_blktrans_thread+0x330/0x3f4
[] kthread+0x88/0x90
[] kernel_thread_helper+0x10/0x18Cc: stable@kernel.org [3.0+]
Signed-off-by: Brian Norris
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
14 Oct, 2011
1 commit
-
This is similar to what the nbd driver does, among others.
Signed-off-by: Dan McGee
Signed-off-by: Artem Bityutskiy
25 May, 2011
1 commit
-
The 'blktrans_open()' does not handle possible '__get_mtd_device()' failures
because it does not check the error code. Moreover, the 'dev->tr->open()'
failures are not handled correctly because in this case the function just
goes ahead and gets the mtd device, then returns an error. But Instead, it
should _not_ try to get the mtd device, then it should put back the module
and the kref.This patch fixes the issue. Note, I only compile-tested it. This patch was
inspired by a bug report about a similar issue in 2.6.34 kernels
sent by Mike Turner to the MTD mailing list:http://lists.infradead.org/pipermail/linux-mtd/2011-April/034980.html
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
25 Mar, 2011
1 commit
-
…linux-2.6 into for-linus-1
* 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6: (9356 commits)
[media] rc: update for bitop name changes
fs: simplify iget & friends
fs: pull inode->i_lock up out of writeback_single_inode
fs: rename inode_lock to inode_hash_lock
fs: move i_wb_list out from under inode_lock
fs: move i_sb_list out from under inode_lock
fs: remove inode_lock from iput_final and prune_icache
fs: Lock the inode LRU list separately
fs: factor inode disposal
fs: protect inode->i_state with inode->i_lock
lib, arch: add filter argument to show_mem and fix private implementations
SLUB: Write to per cpu data when allocating it
slub: Fix debugobjects with lockless fastpath
autofs4: Do not potentially dereference NULL pointer returned by fget() in autofs_dev_ioctl_setpipefd()
autofs4 - remove autofs4_lock
autofs4 - fix d_manage() return on rcu-walk
autofs4 - fix autofs4_expire_indirect() traversal
autofs4 - fix dentry leak in autofs4_expire_direct()
autofs4 - reinstate last used update on access
vfs - check non-mountpoint dentry might block in __follow_mount_rcu()
...NOTE!
This merge commit was created to fix compilation error. The block
tree was merged upstream and removed the 'elv_queue_empty()'
function which the new 'mtdswap' driver is using. So a simple
merge of the mtd tree with upstream does not compile. And the
mtd tree has already be published, so re-basing it is not an option.To fix this unfortunate situation, I had to merge upstream into the
mtd-2.6.git tree without committing, put the fixup patch on top of
this, and then commit this. The result is that we do not have commits
which do not compile.In other words, this merge commit "merges" 3 things: the MTD tree, the
upstream tree, and the fixup patch.
11 Mar, 2011
4 commits
-
Set max_discard_sectors to UINT_MAX.
Signed-off-by: Jarkko Lavinen
Tested-by: Artem Bityutskiy
Signed-off-by: David Woodhouse -
Add a new background method into mtd_blktrans_ops, add background support
into mtd_blktrans_thread(), and add mtd_blktrans_cease_background().If the mtd blktrans dev has the background support, the thread will
call background function when the request queue becomes empty. The background
operation may run as long as needs to until
mtd_blktrans_cease_background() tells to stop.Signed-off-by: Jarkko Lavinen
Tested-by: Artem Bityutskiy
Signed-off-by: David Woodhouse -
The function blktrans_dev_release and blktrans_dev_put are only used
locally in this file and should be static.Signed-off-by: H Hartley Sweeten
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse -
This one liner patch fixes double free that will occur if add_mtd_blktrans_dev
fails. On failure it frees the input argument, but all its users also free it
on error which is natural thing to do. Thus don't free it.All credit for finding that bug belongs to reporters of the bug in the android bugzilla
http://code.google.com/p/android/issues/detail?id=13761Commit message tweaked by Artem.
Signed-off-by: Maxim Levitsky
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
Cc: stable@kernel.org
30 Oct, 2010
3 commits
-
In commit 2a48fc0ab24241755dc93bfd4f01d68efab47f5a ('block: autoconvert
trivial BKL users to private mutex'), Arnd replaced the BKL usage with a
mutex. However, Maxim has already provided a better fix in commit
480792b7bf188c29b8d4b10fee65c3a06ec5dbf7 ('mtd: blktrans: kill BKL'),
which was simply to remove the BKL without replacing it — since he'd
already made it do all necessary locking for itself.Signed-off-by: David Woodhouse
-
Conflicts:
drivers/mtd/mtd_blkdevs.cMerge Grant's device-tree bits so that we can apply the subsequent fixes.
Signed-off-by: David Woodhouse
-
register_blkdev return 1..255 when major = 0.
if (ret ) {
printk(KERN_WARNING "Unable to register %s block device on major %d: %d\n",
tr->name, tr->major, ret);
mutex_unlock(&mtd_table_mutex);
return ret;
}Above code will return fail when register_blkdev return allocated major number.
Signed-off-by: Frank Li
Signed-off-by: David Woodhouse
25 Oct, 2010
3 commits
-
There is small race window that could make kthread_stop hang forever.
I found that while hacking the IR subsystem.Signed-off-by: Maxim Levitsky
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse -
It not needed, because I already added locking for all fops
methods.Signed-off-by: Maxim Levitsky
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse -
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 takenNow 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
Tested-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
05 Oct, 2010
1 commit
-
The block device drivers have all gained new lock_kernel
calls from a recent pushdown, and some of the drivers
were already using the BKL before.This turns the BKL into a set of per-driver mutexes.
Still need to check whether this is safe to do.file=$1
name=$2
if grep -q lock_kernel ${file} ; then
if grep -q 'include.*linux.mutex.h' ${file} ; then
sed -i '/include.*/d' ${file}
else
sed -i 's/include.*.*$/include /g' ${file}
fi
sed -i ${file} \
-e "/^#include.*linux.mutex.h/,$ {
1,/^\(static\|int\|long\)/ {
/^\(static\|int\|long\)/istatic DEFINE_MUTEX(${name}_mutex);} }" \
-e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
-e '/[ ]*cycle_kernel_lock();/d'
else
sed -i -e '/include.*\/d' ${file} \
-e '/cycle_kernel_lock()/d'
fiSigned-off-by: Arnd Bergmann
11 Aug, 2010
1 commit
-
* 'for-2.6.36' of git://git.kernel.dk/linux-2.6-block: (149 commits)
block: make sure that REQ_* types are seen even with CONFIG_BLOCK=n
xen-blkfront: fix missing out label
blkdev: fix blkdev_issue_zeroout return value
block: update request stacking methods to support discards
block: fix missing export of blk_types.h
writeback: fix bad _bh spinlock nesting
drbd: revert "delay probes", feature is being re-implemented differently
drbd: Initialize all members of sync_conf to their defaults [Bugz 315]
drbd: Disable delay probes for the upcomming release
writeback: cleanup bdi_register
writeback: add new tracepoints
writeback: remove unnecessary init_timer call
writeback: optimize periodic bdi thread wakeups
writeback: prevent unnecessary bdi threads wakeups
writeback: move bdi threads exiting logic to the forker thread
writeback: restructure bdi forker loop a little
writeback: move last_active to bdi
writeback: do not remove bdi from bdi_list
writeback: simplify bdi code a little
writeback: do not lose wake-ups in bdi threads
...Fixed up pretty trivial conflicts in drivers/block/virtio_blk.c and
drivers/scsi/scsi_error.c as per Jens.
09 Aug, 2010
1 commit
-
Signed-off-by: David Woodhouse