- 27 Oct, 2010 18 commits
-
-
Namhyung Kim authored
Fix a typo, break long lines and use E3FSBLK on ext3_fsblk_t. Signed-off-by:
Namhyung Kim <namhyung@gmail.com> Signed-off-by:
Jan Kara <jack@suse.cz>
-
Namhyung Kim authored
Convert atomic_inc(&bh->b_count) to get_bh(bh) for consistency. Signed-off-by:
-
Namhyung Kim authored
Signed-off-by:
-
Namhyung Kim authored
'buffer_head' should be 'journal_head'. Signed-off-by:
-
Namhyung Kim authored
Fail journal creation if __getblk() returns NULL. unlikely() is added because it is called in a loop and we've been OK without the check until now. Signed-off-by:
-
Namhyung Kim authored
Signed-off-by:
-
Namhyung Kim authored
Signed-off-by:
-
Namhyung Kim authored
bh->b_data is already a pointer to char so casts to 'char *' should be meaningless. Remove them. Signed-off-by:
-
Namhyung Kim authored
Fix mount-count check to emit warning only if s_max_mnt_count is greater than 0 according to man tune2fs(8). Also removes unnecessary casts. Signed-off-by:
-
Jan Kara authored
__dquot_transfer accidentally called flush_warnings for a wrong set of dquots which could result in quota warnings being issued with a wrong identification. Also when operation fails because of EDQUOT, there's no need check for issuing information message about user getting below limits (no transfer has actually happened). Signed-off-by: -
Dmitry authored
I've got following lockup: dquot_disable dquot_transfer ->dqget() sb_has_quota_active dqopt->flags &= ~dquot_state_flag(f, cnt) atomic_inc(dq->dq_count) ->drop_dquot_ref(sb, cnt); down_write(dqptr_sem) inode->i_dquot[cnt] = NULL ->__dquot_transfer invalidate_dquots(sb, cnt); down_write(&dqptr_sem) ->wait for dq_wait_unused inode->i_dquot = new_dquot /* wait forever */ ^^^^New quota user^^^^^^ We cannot allow new references to dquots from inodes after drop_dquot_ref() has removed them. We have to recheck quota state under dqptr_sem and before assignment, as we do it in dquot_initialize(). Signed-off-by:Dmitry Monakhov <dmonakhov@gmail.com> Signed-off-by:
-
Namhyung Kim authored
Convert set/clear_bit(BH_JWrite, ...) to set/clear_buffer_jwrite() for consistency. Signed-off-by:
-
Darrick J. Wong authored
This fixes a WARN backtrace in mark_buffer_dirty() that occurs during unmount when the underlying block device is removed. This bug has been seen on System Z when removing all paths from a multipath-backed ext3 mount; on System P when injecting enough PCI EEH errors to make the SCSI controller go offline; and similar warnings have been seen (and patched) with ext2/ext4. The super block update from a previous operation has marked the buffer as in error, and the flag has to be cleared before doing the update. Similar changes have been made to ext4 by commit 914258bf. Signed-off-by:
Darrick J. Wong <djwong@us.ibm.com> Signed-off-by:
-
Namhyung Kim authored
Signed-off-by:
-
Namhyung Kim authored
Remove goto statement which jumps to very next line. Also remove target label because it is no longer used anywhere. Signed-off-by:
-
Namhyung Kim authored
Use printk_ratelimited() instead of doing it manually. Signed-off-by:
-
Namhyung Kim authored
Move call to jbd_debug() into #ifdef CONFIG_JBD_DEBUG block because 'dropped' is declared there. The code could be compiled without this change anyway, simply because jbd_debug() expands to nothing if !CONFIG_JBD_DEBUG but IMHO it doesn't look good in general. Signed-off-by:
-
Namhyung Kim authored
@handle doesn't exist in ext2. Remove it. Also, fit comment header into kernel-doc format. Signed-off-by:
-
- 05 Oct, 2010 2 commits
-
-
Jan Kara authored
If a filesystem has inode size > 128 and someone deletes lost+found and reuses inode 11 for some other file, extented attributes set for this inode before umount will get lost after remounting the filesystem. This is because extended attributes will get stored in an inode but ext3_iget will ignore them due to workaround of a bug in an old mkfs. Fix the problem by initializing i_extra_isize to 0 for freshly allocated inodes where mkfs workaround in ext3_iget applies. This way these inodes will always store extended attributes in a special block and no problems occur. The bug was spotted and a reproduction test provided by: Masayoshi MIZUMA <m.mizuma@jp.fujitsu.com> Reviewed-by:
Andreas Dilger <adilger.kernel@dilger.ca> Signed-off-by:
-
Jan Kara authored
Remove "depends on" line from QUOTACTL config option and rather select the option explicitely from config options which need it. It makes more sense this way and also fixes Kconfig warning due to GFS2 selecting QUOTACTL but QUOTACTL not depending on it. Signed-off-by:
-
- 01 Oct, 2010 20 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6: cifs: prevent infinite recursion in cifs_reconnect_tcon cifs: set backing_dev_info on new S_ISREG inodes
-
Linus Torvalds authored
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, hpet: Fix bogus error check in hpet_assign_irq() x86, irq: Plug memory leak in sparse irq x86, cpu: After uncapping CPUID, re-run CPU feature detection
-
David Howells authored
flush_icache_range() is given virtual addresses to describe the region. It deals with these by attempting to translate them through the current set of page tables. This is fine for userspace memory and vmalloc()'d areas as they are governed by page tables. However, since the regions above 0x80000000 aren't translated through the page tables by the MMU, the kernel doesn't bother to set up page tables for them (see paging_init()). This means flush_icache_range() as it stands cannot be used to flush regions of the VM area between 0x80000000 and 0x9fffffff where the kernel resides if the data cache is operating in WriteBack mode. To fix this, make flush_icache_range() first check for addresses in the upper half of VM space and deal with them appropriately, before dealing with any range in the page table mapped area. Ordinarily, this is not a problem, but it has the capacity to make kprobes and kgdb malfunction. It should not affect gdbstub, signal frame setup or module loading as gdb has its own flush functions, and the others take place in the page table mapped area only. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Akira Takeuchi <takeuchi.akr@jp.panasonic.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: vmwgfx: Fix fb VRAM pinning failure due to fragmentation vmwgfx: Remove initialisation of dev::devname vmwgfx: Enable use of the vblank system vmwgfx: vt-switch (master drop) fixes drm/vmwgfx: Fix breakage introduced by commit "drm: block userspace under allocating buffer and having drivers overwrite it (v2)" drm: Hold the mutex when dropping the last GEM reference (v2) drm/gem: handlecount isn't really a kref so don't make it one. drm: i810/i830: fix locked ioctl variant drm/radeon/kms: add quirk for MSI K9A2GM motherboard drm/radeon/kms: fix potential segfault in r600_ioctl_wait_idle drm: Prune GEM vma entries drm/radeon/kms: fix up encoder info messages for DFP6 drm/radeon: fix PCI ID 5657 to be an RV410
-
git://git.fluff.org/bjdooks/linuxLinus Torvalds authored
* 'for-linus/i2c/2636-rc5' of git://git.fluff.org/bjdooks/linux: i2c-s3c2410: fix calculation of SDA line delay i2c-davinci: Fix race when setting up for TX i2c-octeon: Return -ETIMEDOUT in octeon_i2c_wait() on timeout
-
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: ACPI: invoke DSDT corruption workaround on all Toshiba Satellite ACPI, APEI, Fix ERST MOVE_DATA instruction implementation ACPI: fan: Fix more unbalanced code block ACPI: acpi_pad: simplify code to avoid false gcc build warning ACPI, APEI, Fix error path for memory allocation ACPI, APEI, HEST Fix the unsuitable usage of platform_data ACPI, APEI, Fix acpi_pre_map() return value ACPI, APEI, Fix APEI related table size checking ACPI: Disable Windows Vista compatibility for Toshiba P305D ACPI: Kconfig: fix typo. ACPI: add missing __percpu markup in arch/x86/kernel/acpi/cstate.c ACPI: Fix typos ACPI video: fix a poor warning message ACPI: fix build warnings resulting from merge window conflict ACPI: EC: add Vista incompatibility DMI entry for Toshiba Satellite L355 ACPI: expand Vista blacklist to include SP1 and SP2 ACPI: delete ZEPTO idle=nomwait DMI quirk ACPI: enable repeated PCIEXP wakeup by clearing PCIEXP_WAKE_STS on resume PM / ACPI: Blacklist systems known to require acpi_sleep=nonvs ACPI: Don't report current_now if battery reports in mWh
-
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6Linus Torvalds authored
* 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6: intel_idle: Voluntary leave_mm before entering deeper acpi_idle: add missing \n to printk intel_idle: add missing __percpu markup intel_idle: Change mode 755 => 644 cpuidle: Fix typos intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hang
-
Linus Torvalds authored
Merge branch 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 * 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: omap: McBSP: tx_irq_completion used in rx_irq_handler omap: Fix compile dependency to LEDS_CLASS
-
Frederic Weisbecker authored
Prevent from recursively locking the reiserfs lock in reiserfs_unpack() because we may call journal_begin() that requires the lock to be taken only once, otherwise it won't be able to release the lock while taking other mutexes, ending up in inverted dependencies between the journal mutex and the reiserfs lock for example. This fixes: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.35.4.4a #3 ------------------------------------------------------- lilo/1620 is trying to acquire lock: (&journal->j_mutex){+.+...}, at: [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs] but task is already holding lock: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&REISERFS_SB(s)->lock){+.+.+.}: [<c10562b7>] lock_acquire+0x67/0x80 [<c12facad>] __mutex_lock_common+0x4d/0x410 [<c12fb0c8>] mutex_lock_nested+0x18/0x20 [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs] [<d0325c06>] do_journal_begin_r+0x86/0x340 [reiserfs] [<d0325f77>] journal_begin+0x77/0x140 [reiserfs] [<d0315be4>] reiserfs_remount+0x224/0x530 [reiserfs] [<c10b6a20>] do_remount_sb+0x60/0x110 [<c10cee25>] do_mount+0x625/0x790 [<c10cf014>] sys_mount+0x84/0xb0 [<c12fca3d>] syscall_call+0x7/0xb -> #0 (&journal->j_mutex){+.+...}: [<c10560f6>] __lock_acquire+0x1026/0x1180 [<c10562b7>] lock_acquire+0x67/0x80 [<c12facad>] __mutex_lock_common+0x4d/0x410 [<c12fb0c8>] mutex_lock_nested+0x18/0x20 [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs] [<d0325f77>] journal_begin+0x77/0x140 [reiserfs] [<d0326271>] reiserfs_persistent_transaction+0x41/0x90 [reiserfs] [<d030d06c>] reiserfs_get_block+0x22c/0x1530 [reiserfs] [<c10db9db>] __block_prepare_write+0x1bb/0x3a0 [<c10dbbe6>] block_prepare_write+0x26/0x40 [<d030b738>] reiserfs_prepare_write+0x88/0x170 [reiserfs] [<d03294d6>] reiserfs_unpack+0xe6/0x120 [reiserfs] [<d0329782>] reiserfs_ioctl+0x272/0x320 [reiserfs] [<c10c3188>] vfs_ioctl+0x28/0xa0 [<c10c3bbd>] do_vfs_ioctl+0x32d/0x5c0 [<c10c3eb3>] sys_ioctl+0x63/0x70 [<c12fca3d>] syscall_call+0x7/0xb other info that might help us debug this: 2 locks held by lilo/1620: #0: (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<d032945a>] reiserfs_unpack+0x6a/0x120 [reiserfs] #1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs] stack backtrace: Pid: 1620, comm: lilo Not tainted 2.6.35.4.4a #3 Call Trace: [<c10560f6>] __lock_acquire+0x1026/0x1180 [<c10562b7>] lock_acquire+0x67/0x80 [<c12facad>] __mutex_lock_common+0x4d/0x410 [<c12fb0c8>] mutex_lock_nested+0x18/0x20 [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs] [<d0325f77>] journal_begin+0x77/0x140 [reiserfs] [<d0326271>] reiserfs_persistent_transaction+0x41/0x90 [reiserfs] [<d030d06c>] reiserfs_get_block+0x22c/0x1530 [reiserfs] [<c10db9db>] __block_prepare_write+0x1bb/0x3a0 [<c10dbbe6>] block_prepare_write+0x26/0x40 [<d030b738>] reiserfs_prepare_write+0x88/0x170 [reiserfs] [<d03294d6>] reiserfs_unpack+0xe6/0x120 [reiserfs] [<d0329782>] reiserfs_ioctl+0x272/0x320 [reiserfs] [<c10c3188>] vfs_ioctl+0x28/0xa0 [<c10c3bbd>] do_vfs_ioctl+0x32d/0x5c0 [<c10c3eb3>] sys_ioctl+0x63/0x70 [<c12fca3d>] syscall_call+0x7/0xb Reported-by:Jarek Poplawski <jarkao2@gmail.com> Tested-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: Jeff Mahoney <jeffm@suse.com> Cc: All since 2.6.32 <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Frederic Weisbecker authored
The reiserfs mutex already depends on the inode mutex, so we can't lock the inode mutex in reiserfs_unpack() without using the safe locking API, because reiserfs_unpack() is always called with the reiserfs mutex locked. This fixes: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.35c #13 ------------------------------------------------------- lilo/1606 is trying to acquire lock: (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs] but task is already holding lock: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&REISERFS_SB(s)->lock){+.+.+.}: [<c1056347>] lock_acquire+0x67/0x80 [<c12f083d>] __mutex_lock_common+0x4d/0x410 [<c12f0c58>] mutex_lock_nested+0x18/0x20 [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs] [<d0329e9a>] reiserfs_lookup_privroot+0x2a/0x90 [reiserfs] [<d0316b81>] reiserfs_fill_super+0x941/0xe60 [reiserfs] [<c10b7d17>] get_sb_bdev+0x117/0x170 [<d0313e21>] get_super_block+0x21/0x30 [reiserfs] [<c10b74ba>] vfs_kern_mount+0x6a/0x1b0 [<c10b7659>] do_kern_mount+0x39/0xe0 [<c10cebe0>] do_mount+0x340/0x790 [<c10cf0b4>] sys_mount+0x84/0xb0 [<c12f25cd>] syscall_call+0x7/0xb -> #0 (&sb->s_type->i_mutex_key#8){+.+.+.}: [<c1056186>] __lock_acquire+0x1026/0x1180 [<c1056347>] lock_acquire+0x67/0x80 [<c12f083d>] __mutex_lock_common+0x4d/0x410 [<c12f0c58>] mutex_lock_nested+0x18/0x20 [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs] [<d0329772>] reiserfs_ioctl+0x272/0x320 [reiserfs] [<c10c3228>] vfs_ioctl+0x28/0xa0 [<c10c3c5d>] do_vfs_ioctl+0x32d/0x5c0 [<c10c3f53>] sys_ioctl+0x63/0x70 [<c12f25cd>] syscall_call+0x7/0xb other info that might help us debug this: 1 lock held by lilo/1606: #0: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs] stack backtrace: Pid: 1606, comm: lilo Not tainted 2.6.35c #13 Call Trace: [<c1056186>] __lock_acquire+0x1026/0x1180 [<c1056347>] lock_acquire+0x67/0x80 [<c12f083d>] __mutex_lock_common+0x4d/0x410 [<c12f0c58>] mutex_lock_nested+0x18/0x20 [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs] [<d0329772>] reiserfs_ioctl+0x272/0x320 [reiserfs] [<c10c3228>] vfs_ioctl+0x28/0xa0 [<c10c3c5d>] do_vfs_ioctl+0x32d/0x5c0 [<c10c3f53>] sys_ioctl+0x63/0x70 [<c12f25cd>] syscall_call+0x7/0xb Reported-by: -
Kukjin Kim authored
Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Acked-by:
Ben Dooks <ben-linux@fluff.org> Acked-by:
Russell King <rmk@arm.linux.org.uk> Cc: Kyungmin Park <kmpark@infradead.org> Signed-off-by:
-
Petr Vandrovec authored
I moved couple years ago, so let's update my email and snail mail. And I do not have any access to Matrox hardware anymore, and I'm quite unresponsive to matroxfb bug reports (sorry Alan), so saying that I'm maintainer is a bit far fetched. For ncpfs I do not use ncpfs in my daily life either, but at least I can test that one, so I can stay listed here for odd fixes. Signed-off-by:
Petr Vandrovec <petr@vandrovec.name> Signed-off-by:
-
Jiri Olsa authored
Having the limits file world readable will ease the task of system management on systems where root privileges might be restricted. Having admin restricted with root priviledges, he/she could not check other users process' limits. Also it'd align with most of the /proc stat files. Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Cc: Eugene Teo <eugene@redhat.com> Signed-off-by:
-
Don Mullis authored
If the original list is a POT in length, the first callback from line 73 will pass a==b both pointing to the original list_head. This is dangerous because the 'list_sort()' user can use 'container_of()' and accesses the "containing" object, which does not necessary exist for the list head. So the user can access RAM which does not belong to him. If this is a write access, we can end up with memory corruption. Signed-off-by:
Don Mullis <don.mullis@gmail.com> Tested-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
-
Dan Rosenberg authored
The semctl syscall has several code paths that lead to the leakage of uninitialized kernel stack memory (namely the IPC_INFO, SEM_INFO, IPC_STAT, and SEM_STAT commands) during the use of the older, obsolete version of the semid_ds struct. The copy_semid_to_user() function declares a semid_ds struct on the stack and copies it back to the user without initializing or zeroing the "sem_base", "sem_pending", "sem_pending_last", and "undo" pointers, allowing the leakage of 16 bytes of kernel stack memory. The code is still reachable on 32-bit systems - when calling semctl() newer glibc's automatically OR the IPC command with the IPC_64 flag, but invoking the syscall directly allows users to use the older versions of the struct. Signed-off-by:
Dan Rosenberg <dan.j.rosenberg@gmail.com> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Marcin Slusarz authored
Array of udimm sysfs attributes was not ended with NULL marker, leading to dereference of random memory. EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm0 EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm1 EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm2 BUG: unable to handle kernel NULL pointer dereference at 00000000000001a4 IP: [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1 Pid: 1, comm: swapper Not tainted 2.6.36-rc3-nv+ #483 P6T SE/System Product Name RIP: 0010:[<ffffffff81330b36>] [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1 (...) Call Trace: [<ffffffff81330b86>] edac_create_mci_instance_attributes+0x198/0x1f1 [<ffffffff81330c9a>] edac_create_sysfs_mci_device+0xbb/0x2b2 [<ffffffff8132f533>] edac_mc_add_mc+0x46b/0x557 [<ffffffff81428901>] i7core_probe+0xccf/0xec0 RIP [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1 ---[ end trace 20de320855b81d78 ]--- Kernel panic - not syncing: Attempted to kill init! Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by:
Doug Thompson <dougthompson@xmission.com> Cc: <stable@kernel.org> Signed-off-by:
-
Andrew Morton authored
sparc64 allmodconfig: drivers/serial/mrst_max3110.c: In function `serial_m3110_startup': drivers/serial/mrst_max3110.c:470: error: `IRQ_TYPE_EDGE_FALLING' undeclared (first use in this function) Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Andrew Morton authored
Fix the warnings arch/m68k/mac/macboing.c: In function 'mac_mksound': arch/m68k/mac/macboing.c:189: warning: comparison of distinct pointer types lacks a cast arch/m68k/mac/macboing.c:211: warning: comparison of distinct pointer types lacks a cast arch/m68k/mac/macboing.c: In function 'mac_quadra_start_bell': arch/m68k/mac/macboing.c:241: warning: comparison of distinct pointer types lacks a cast arch/m68k/mac/macboing.c:263: warning: comparison of distinct pointer types lacks a cast arch/m68k/mac/macboing.c: In function 'mac_quadra_ring_bell': arch/m68k/mac/macboing.c:283: warning: comparison of distinct pointer types lacks a cast Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Andrew Morton authored
alpha allmodconfig: drivers/serial/mfd.c:144: error: implicit declaration of function 'kzalloc' drivers/serial/mfd.c:144: warning: assignment makes pointer from integer without a cast Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Ira W. Snyder authored
The kfifo_dma family of functions use sg_mark_end() on the last element in their scatterlist. This forces use of a fresh scatterlist for each DMA operation, which makes recycling a single scatterlist impossible. Change the behavior of the kfifo_dma functions to match the usage of the dma_map_sg function. This means that users must respect the returned nents value. The sample code is updated to reflect the change. This bug is trivial to cause: call kfifo_dma_in_prepare() such that it prepares a scatterlist with a single entry comprising the whole fifo. This is the case when you map the entirety of a newly created empty fifo. This causes the setup_sgl() function to mark the first scatterlist entry as the end of the chain, no matter what comes after it. Afterwards, add and remove some data from the fifo such that another call to kfifo_dma_in_prepare() will create two scatterlist entries. It returns nents=2. However, due to the previous sg_mark_end() call, sg_is_last() will now return true for the first scatterlist element. This causes the sample code to print a single scatterlist element when it should print two. By removing the call to sg_mark_end(), we make the API as similar as possible to the DMA mapping API. All users are required to respect the returned nents. Signed-off-by:
Ira W. Snyder <iws@ovro.caltech.edu> Cc: Stefani Seibold <stefani@seibold.net> Signed-off-by:
-
