- 20 Oct, 2014 40 commits
-
-
Prarit Bhargava authored
commit d3051b48 upstream. A panic was seen in the following sitation. There are two threads running on the system. The first thread is a system monitoring thread that is reading /proc/modules. The second thread is loading and unloading a module (in this example I'm using my simple dummy-module.ko). Note, in the "real world" this occurred with the qlogic driver module. When doing this, the following panic occurred: ------------[ cut here ]------------ kernel BUG at kernel/module.c:3739! invalid opcode: 0000 [#1] SMP Modules linked in: binfmt_misc sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw igb gf128mul glue_helper iTCO_wdt iTCO_vendor_support ablk_helper ptp sb_edac cryptd pps_core edac_core shpchp i2c_i801 pcspkr wmi lpc_ich ioatdma mfd_core dca ipmi_si nfsd ipmi_msghandler auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm isci drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: dummy_module] CPU: 37 PID: 186343 Comm: cat Tainted: GF O-------------- 3.10.0+ #7 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013 task: ffff8807fd2d8000 ti: ffff88080fa7c000 task.ti: ffff88080fa7c000 RIP: 0010:[<ffffffff810d64c5>] [<ffffffff810d64c5>] module_flags+0xb5/0xc0 RSP: 0018:ffff88080fa7fe18 EFLAGS: 00010246 RAX: 0000000000000003 RBX: ffffffffa03b5200 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffff88080fa7fe38 RDI: ffffffffa03b5000 RBP: ffff88080fa7fe28 R08: 0000000000000010 R09: 0000000000000000 R10: 0000000000000000 R11: 000000000000000f R12: ffffffffa03b5000 R13: ffffffffa03b5008 R14: ffffffffa03b5200 R15: ffffffffa03b5000 FS: 00007f6ae57ef740(0000) GS:ffff88101e7a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000404f70 CR3: 0000000ffed48000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffffffffa03b5200 ffff8810101e4800 ffff88080fa7fe70 ffffffff810d666c ffff88081e807300 000000002e0f2fbf 0000000000000000 ffff88100f257b00 ffffffffa03b5008 ffff88080fa7ff48 ffff8810101e4800 ffff88080fa7fee0 Call Trace: [<ffffffff810d666c>] m_show+0x19c/0x1e0 [<ffffffff811e4d7e>] seq_read+0x16e/0x3b0 [<ffffffff812281ed>] proc_reg_read+0x3d/0x80 [<ffffffff811c0f2c>] vfs_read+0x9c/0x170 [<ffffffff811c1a58>] SyS_read+0x58/0xb0 [<ffffffff81605829>] system_call_fastpath+0x16/0x1b Code: 48 63 c2 83 c2 01 c6 04 03 29 48 63 d2 eb d9 0f 1f 80 00 00 00 00 48 63 d2 c6 04 13 2d 41 8b 0c 24 8d 50 02 83 f9 01 75 b2 eb cb <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 RIP [<ffffffff810d64c5>] module_flags+0xb5/0xc0 RSP <ffff88080fa7fe18> Consider the two processes running on the system. CPU 0 (/proc/modules reader) CPU 1 (loading/unloading module) CPU 0 opens /proc/modules, and starts displaying data for each module by traversing the modules list via fs/seq_file.c:seq_open() and fs/seq_file.c:seq_read(). For each module in the modules list, seq_read does op->start() <-- this is a pointer to m_start() op->show() <- this is a pointer to m_show() op->stop() <-- this is a pointer to m_stop() The m_start(), m_show(), and m_stop() module functions are defined in kernel/module.c. The m_start() and m_stop() functions acquire and release the module_mutex respectively. ie) When reading /proc/modules, the module_mutex is acquired and released for each module. m_show() is called with the module_mutex held. It accesses the module struct data and attempts to write out module data. It is in this code path that the above BUG_ON() warning is encountered, specifically m_show() calls static char *module_flags(struct module *mod, char *buf) { int bx = 0; BUG_ON(mod->state == MODULE_STATE_UNFORMED); ... The other thread, CPU 1, in unloading the module calls the syscall delete_module() defined in kernel/module.c. The module_mutex is acquired for a short time, and then released. free_module() is called without the module_mutex. free_module() then sets mod->state = MODULE_STATE_UNFORMED, also without the module_mutex. Some additional code is called and then the module_mutex is reacquired to remove the module from the modules list: /* Now we can delete it from the lists */ mutex_lock(&module_mutex); stop_machine(__unlink_module, mod, NULL); mutex_unlock(&module_mutex); This is the sequence of events that leads to the panic. CPU 1 is removing dummy_module via delete_module(). It acquires the module_mutex, and then releases it. CPU 1 has NOT set dummy_module->state to MODULE_STATE_UNFORMED yet. CPU 0, which is reading the /proc/modules, acquires the module_mutex and acquires a pointer to the dummy_module which is still in the modules list. CPU 0 calls m_show for dummy_module. The check in m_show() for MODULE_STATE_UNFORMED passed for dummy_module even though it is being torn down. Meanwhile CPU 1, which has been continuing to remove dummy_module without holding the module_mutex, now calls free_module() and sets dummy_module->state to MODULE_STATE_UNFORMED. CPU 0 now calls module_flags() with dummy_module and ... static char *module_flags(struct module *mod, char *buf) { int bx = 0; BUG_ON(mod->state == MODULE_STATE_UNFORMED); and BOOM. Acquire and release the module_mutex lock around the setting of MODULE_STATE_UNFORMED in the teardown path, which should resolve the problem. Testing: In the unpatched kernel I can panic the system within 1 minute by doing while (true) do insmod dummy_module.ko; rmmod dummy_module.ko; done and while (true) do cat /proc/modules; done in separate terminals. In the patched kernel I was able to run just over one hour without seeing any issues. I also verified the output of panic via sysrq-c and the output of /proc/modules looks correct for all three states for the dummy_module. dummy_module 12661 0 - Unloading 0xffffffffa03a5000 (OE-) dummy_module 12661 0 - Live 0xffffffffa03bb000 (OE) dummy_module 14015 1 - Loading 0xffffffffa03a5000 (OE+) Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Eric W. Biederman authored
commit 0d082601 upstream. Andy Lutomirski recently demonstrated that when chroot is used to set the root path below the path for the new ``root'' passed to pivot_root the pivot_root system call succeeds and leaks mounts. In examining the code I see that starting with a new root that is below the current root in the mount tree will result in a loop in the mount tree after the mounts are detached and then reattached to one another. Resulting in all kinds of ugliness including a leak of that mounts involved in the leak of the mount loop. Prevent this problem by ensuring that the new mount is reachable from the current root of the mount tree. [Added stable cc. Fixes CVE-2014-7970. --Andy] Reported-by:
Andy Lutomirski <luto@amacapital.net> Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Ilya Dryomov authored
commit f9865f06 upstream. Commit f363e45f ("net/ceph: make ceph_msgr_wq non-reentrant") effectively removed WQ_MEM_RECLAIM flag from ceph_msgr_wq. This is wrong - libceph is very much a memory reclaim path, so restore it. Signed-off-by:
Ilya Dryomov <idryomov@redhat.com> Tested-by:
Micha Krause <micha@krausam.de> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
-
Takashi Iwai authored
commit 95926035 upstream. The emu10k1 voice allocator takes voice_lock spinlock. When there is no empty stream available, it tries to release a voice used by synth, and calls get_synth_voice. The callback function, snd_emu10k1_synth_get_voice(), however, also takes the voice_lock, thus it deadlocks. The fix is simply removing the voice_lock holds in snd_emu10k1_synth_get_voice(), as this is always called in the spinlock context. Reported-and-tested-by:
Arthur Marsh <arthur.marsh@internode.on.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Sasha Levin authored
commit 71458cfc upstream. We're missing include/linux/compiler-gcc5.h which is required now because gcc branched off to v5 in trunk. Just copy the relevant bits out of include/linux/compiler-gcc4.h, no new code is added as of now. This fixes a build error when using gcc 5. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Thorsten Knabe authored
commit 2a236122 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug was introduced by commit 805f11a0 (um: ubd: Add REQ_FLUSH suppport). Fix bug by adding a check if FLUSH request was successfully submitted to the I/O thread and keeping the FLUSH request on the request queue on submission failures. Fixes: 805f11a0 (um: ubd: Add REQ_FLUSH suppport) Signed-off-by:
Thorsten Knabe <linux@thorsten-knabe.de> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Hans de Goede authored
commit 9ff84a17 upstream. Without this the aux port does not get detected, and consequently the touchpad will not work. https://bugzilla.redhat.com/show_bug.cgi?id=1110011Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
commit aa972409 upstream. Unfortunately, ForcePad capability is not actually exported over PS/2, so we have to resort to DMI checks. Reported-by:
Nicole Faerber <nicole.faerber@kernelconcepts.de> Signed-off-by:
-
Junxiao Bi authored
commit 934f3072 upstream. commit 21caf2fc ("mm: teach mm by current context info to not do I/O during memory allocation") introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory allocation, __GFP_IO is cleared when this flag is set, but __GFP_FS implies __GFP_IO, it should also be cleared. Or it may still run into I/O, like in superblock shrinker. And this will make the kernel run into the deadlock case described in that commit. See Dave Chinner's comment about io in superblock shrinker: Filesystem shrinkers do indeed perform IO from the superblock shrinker and have for years. Even clean inodes can require IO before they can be freed - e.g. on an orphan list, need truncation of post-eof blocks, need to wait for ordered operations to complete before it can be freed, etc. IOWs, Ext4, btrfs and XFS all can issue and/or block on arbitrary amounts of IO in the superblock shrinker context. XFS, in particular, has been doing transactions and IO from the VFS inode cache shrinker since it was first introduced.... Fix this by clearing __GFP_FS in memalloc_noio_flags(), this function has masked all the gfp_mask that will be passed into fs for the processes setting PF_MEMALLOC_NOIO in the direct reclaim path. v1 thread at: https://lkml.org/lkml/2014/9/3/32Signed-off-by:
Junxiao Bi <junxiao.bi@oracle.com> Cc: Dave Chinner <david@fromorbit.com> Cc: joyce.xue <xuejiufei@huawei.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Yann Droneaud authored
commit 0b37e097 upstream. According to commit 80af2588 ("fanotify: groups can specify their f_flags for new fd"), file descriptors created as part of file access notification events inherit flags from the event_f_flags argument passed to syscall fanotify_init(2)[1]. Unfortunately O_CLOEXEC is currently silently ignored. Indeed, event_f_flags are only given to dentry_open(), which only seems to care about O_ACCMODE and O_PATH in do_dentry_open(), O_DIRECT in open_check_o_direct() and O_LARGEFILE in generic_file_open(). It's a pity, since, according to some lookup on various search engines and http://codesearch.debian.net/, there's already some userspace code which use O_CLOEXEC: - in systemd's readahead[2]: fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME); - in clsync[3]: #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC) int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS); - in examples [4] from "Filesystem monitoring in the Linux kernel" article[5] by Aleksander Morgado: if ((fanotify_fd = fanotify_init (FAN_CLOEXEC, O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0) Additionally, since commit 48149e9d ("fanotify: check file flags passed in fanotify_init"). having O_CLOEXEC as part of fanotify_init() second argument is expressly allowed. So it seems expected to set close-on-exec flag on the file descriptors if userspace is allowed to request it with O_CLOEXEC. But Andrew Morton raised[6] the concern that enabling now close-on-exec might break existing applications which ask for O_CLOEXEC but expect the file descriptor to be inherited across exec(). In the other hand, as reported by Mihai Dontu[7] close-on-exec on the file descriptor returned as part of file access notify can break applications due to deadlock. So close-on-exec is needed for most applications. More, applications asking for close-on-exec are likely expecting it to be enabled, relying on O_CLOEXEC being effective. If not, it might weaken their security, as noted by Jan Kara[8]. So this patch replaces call to macro get_unused_fd() by a call to function get_unused_fd_flags() with event_f_flags value as argument. This way O_CLOEXEC flag in the second argument of fanotify_init(2) syscall is interpreted and close-on-exec get enabled when requested. [1] http://man7.org/linux/man-pages/man2/fanotify_init.2.html [2] http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-collect.c?id=v208#n294 [3] https://github.com/xaionaro/clsync/blob/v0.2.1/sync.c#L1631 https://github.com/xaionaro/clsync/blob/v0.2.1/configuration.h#L38 [4] http://www.lanedo.com/~aleksander/fanotify/fanotify-example.c [5] http://www.lanedo.com/2013/filesystem-monitoring-linux-kernel/ [6] http://lkml.kernel.org/r/20141001153621.65e9258e65a6167bf2e4cb50@linux-foundation.org [7] http://lkml.kernel.org/r/20141002095046.3715eb69@mdontu-l [8] http://lkml.kernel.org/r/20141002104410.GB19748@quack.suse.cz Link: http://lkml.kernel.org/r/cover.1411562410.git.ydroneaud@opteya.comSigned-off-by:
Yann Droneaud <ydroneaud@opteya.com> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Mihai Don\u021bu <mihai.dontu@gmail.com> Cc: Pádraig Brady <P@draigBrady.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Jan Kara <jack@suse.cz> Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Cc: Michael Kerrisk-manpages <mtk.manpages@gmail.com> Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de> Cc: Richard Guy Briggs <rgb@redhat.com> Cc: Eric Paris <eparis@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by:
-
Mike Snitzer authored
commit b8839b8c upstream. The math in both blk_stack_limits() and queue_limit_alignment_offset() assume that a block device's io_min (aka minimum_io_size) is always a power-of-2. Fix the math such that it works for non-power-of-2 io_min. This issue (of alignment_offset != 0) became apparent when testing dm-thinp with a thinp blocksize that matches a RAID6 stripesize of 1280K. Commit fdfb4c8c ("dm thin: set minimum_io_size to pool's data block size") unlocked the potential for alignment_offset != 0 due to the dm-thin-pool's io_min possibly being a non-power-of-2. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Al Viro authored
commit 24dff96a upstream. we used to check for "nobody else could start doing anything with that opened file" by checking that refcount was 2 or less - one for descriptor table and one we'd acquired in fget() on the way to wherever we are. That was race-prone (somebody else might have had a reference to descriptor table and do fget() just as we'd been checking) and it had become flat-out incorrect back when we switched to fget_light() on those codepaths - unlike fget(), it doesn't grab an extra reference unless the descriptor table is shared. The same change allowed a race-free check, though - we are safe exactly when refcount is less than 2. It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading to ppp one) and 2.6.17 for sendmsg() (netlink one). OTOH, netlink hadn't grown that check until 3.9 and ppp used to live in drivers/net, not drivers/net/ppp until 3.1. The bug existed well before that, though, and the same fix used to apply in old location of file. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Mikulas Patocka authored
commit c2ca0fcd upstream. This patch makes it possible to kill a process looping in cont_expand_zero. A process may spend a lot of time in this function, so it is desirable to be able to kill it. It happened to me that I wanted to copy a piece data from the disk to a file. By mistake, I used the "seek" parameter to dd instead of "skip". Due to the "seek" parameter, dd attempted to extend the file and became stuck doing so - the only possibility was to reset the machine or wait many hours until the filesystem runs out of space and cont_expand_zero fails. We need this patch to be able to terminate the process. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Tetsuo Handa authored
commit 475d0db7 upstream. total_objects could be 0 and is used as a denom. While total_objects is a "long", total_objects == 0 unlikely happens for 3.12 and later kernels because 32-bit architectures would not be able to hold (1 << 32) objects. However, total_objects == 0 may happen for kernels between 3.1 and 3.11 because total_objects in prune_super() was an "int" and (e.g.) x86_64 architecture might be able to hold (1 << 32) objects. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Al Viro authored
commit 99358a1c upstream. schedule_delayed_work() happening when the work is already pending is a cheap no-op. Don't bother with ->wbuf_queued logics - it's both broken (cancelling ->wbuf_dwork leaves it set, as spotted by Jeff Harris) and pointless. It's cheaper to let schedule_delayed_work() handle that case. Reported-by:
Jeff Harris <jefftharris@gmail.com> Tested-by:
-
Ben Hutchings authored
commit 0e6d3112 upstream. It is currently possible to execve() an x32 executable on an x86_64 kernel that has only ia32 compat enabled. However all its syscalls will fail, even _exit(). This usually causes it to segfault. Change the ELF compat architecture check so that x32 executables are rejected if we don't support the x32 ABI. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Link: http://lkml.kernel.org/r/1410120305.6822.9.camel@decadent.org.ukSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 1e99cfa8 upstream. The translation from the X driver to the KMS one typo'ed a couple of array indices, causing the HW cursor to look weird (blocky with leaking edge colors). This fixes it. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Scott Carter authored
commit 37017ac6 upstream. The Broadcom OSB4 IDE Controller (vendor and device IDs: 1166:0211) does not support 64-KB DMA transfers. Whenever a 64-KB DMA transfer is attempted, the transfer fails and messages similar to the following are written to the console log: [ 2431.851125] sr 0:0:0:0: [sr0] Unhandled sense code [ 2431.851139] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 2431.851152] sr 0:0:0:0: [sr0] Sense Key : Hardware Error [current] [ 2431.851166] sr 0:0:0:0: [sr0] Add. Sense: Logical unit communication time-out [ 2431.851182] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 76 f4 00 00 40 00 [ 2431.851210] end_request: I/O error, dev sr0, sector 121808 When the libata and pata_serverworks modules are recompiled with ATA_DEBUG and ATA_VERBOSE_DEBUG defined in libata.h, the 64-KB transfer size in the scatter-gather list can be seen in the console log: [ 2664.897267] sr 9:0:0:0: [sr0] Send: [ 2664.897274] 0xf63d85e0 [ 2664.897283] sr 9:0:0:0: [sr0] CDB: [ 2664.897288] Read(10): 28 00 00 00 7f b4 00 00 40 00 [ 2664.897319] buffer = 0xf6d6fbc0, bufflen = 131072, queuecommand 0xf81b7700 [ 2664.897331] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 7f b4 00 00 40 [ 2664.897338] ata_scsi_translate: ENTER [ 2664.897345] ata_sg_setup: ENTER, ata1 [ 2664.897356] ata_sg_setup: 3 sg elements mapped [ 2664.897364] ata_bmdma_fill_sg: PRD[0] = (0x66FD2000, 0xE000) [ 2664.897371] ata_bmdma_fill_sg: PRD[1] = (0x65000000, 0x10000) ------------------------------------------------------> ======= [ 2664.897378] ata_bmdma_fill_sg: PRD[2] = (0x66A10000, 0x2000) [ 2664.897386] ata1: ata_dev_select: ENTER, device 0, wait 1 [ 2664.897422] ata_sff_tf_load: feat 0x1 nsect 0x0 lba 0x0 0x0 0xFC [ 2664.897428] ata_sff_tf_load: device 0xA0 [ 2664.897448] ata_sff_exec_command: ata1: cmd 0xA0 [ 2664.897457] ata_scsi_translate: EXIT [ 2664.897462] leaving scsi_dispatch_cmnd() [ 2664.897497] Doing sr request, dev = sr0, block = 0 [ 2664.897507] sr0 : reading 64/256 512 byte blocks. [ 2664.897553] ata_sff_hsm_move: ata1: protocol 7 task_state 1 (dev_stat 0x58) [ 2664.897560] atapi_send_cdb: send cdb [ 2666.910058] ata_bmdma_port_intr: ata1: host_stat 0x64 [ 2666.910079] __ata_sff_port_intr: ata1: protocol 7 task_state 3 [ 2666.910093] ata_sff_hsm_move: ata1: protocol 7 task_state 3 (dev_stat 0x51) [ 2666.910101] ata_sff_hsm_move: ata1: protocol 7 task_state 4 (dev_stat 0x51) [ 2666.910129] sr 9:0:0:0: [sr0] Done: [ 2666.910136] 0xf63d85e0 TIMEOUT lspci shows that the driver used for the Broadcom OSB4 IDE Controller is pata_serverworks: 00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8e [Master SecP SecO PriP]) Flags: bus master, medium devsel, latency 64 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=4] I/O ports at 1440 [size=16] Kernel driver in use: pata_serverworks The pata_serverworks driver supports five distinct device IDs, one being the OSB4 and the other four belonging to the CSB series. The CSB series appears to support 64-KB DMA transfers, as tests on a machine with an SAI2 motherboard containing a Broadcom CSB5 IDE Controller (vendor and device IDs: 1166:0212) showed no problems with 64-KB DMA transfers. This problem was first discovered when attempting to install openSUSE from a DVD on a machine with an STL2 motherboard. Using the pata_serverworks module, older releases of openSUSE will not install at all due to the timeouts. Releases of openSUSE prior to 11.3 can be installed by disabling the pata_serverworks module using the brokenmodules boot parameter, which causes the serverworks module to be used instead. Recent releases of openSUSE (12.2 and later) include better error recovery and will install, though very slowly. On all openSUSE releases, the problem can be recreated on a machine containing a Broadcom OSB4 IDE Controller by mounting an install DVD and running a command similar to the following: find /mnt -type f -print | xargs cat > /dev/null The patch below corrects the problem. Similar to the other ATA drivers that do not support 64-KB DMA transfers, the patch changes the ata_port_operations qc_prep vector to point to a routine that breaks any 64-KB segment into two 32-KB segments and changes the scsi_host_template sg_tablesize element to reduce by half the number of scatter/gather elements allowed. These two changes affect only the OSB4. Signed-off-by:
Scott Carter <ccscott@funsoft.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Daniel Mack authored
commit e5092c96 upstream. Coverity spotted the following possible use-after-free condition in dapm_create_or_share_mixmux_kcontrol(): If kcontrol is NULL, and (wname_in_long_name && kcname_in_long_name) validates to true, 'name' will be set to an allocated string, and be freed a few lines later via the 'long_name' alias. 'name', however, is used by dev_err() in case snd_ctl_add() fails. Fix this by adding a jump label that frees 'long_name' at the end of the function. Signed-off-by:
Daniel Mack <daniel@zonque.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Andy Lutomirski authored
commit 8c7aa698 upstream. The NT flag doesn't do anything in long mode other than causing IRET to #GP. Oddly, CPL3 code can still set NT using popf. Entry via hardware or software interrupt clears NT automatically, so the only relevant entries are fast syscalls. If user code causes kernel code to run with NT set, then there's at least some (small) chance that it could cause trouble. For example, user code could cause a call to EFI code with NT set, and who knows what would happen? Apparently some games on Wine sometimes do this (!), and, if an IRET return happens, they will segfault. That segfault cannot be handled, because signal delivery fails, too. This patch programs the CPU to clear NT on entry via SYSCALL (both 32-bit and 64-bit, by my reading of the AMD APM), and it clears NT in software on entry via SYSENTER. To save a few cycles, this borrows a trick from Jan Beulich in Xen: it checks whether NT is set before trying to clear it. As a result, it seems to have very little effect on SYSENTER performance on my machine. There's another minor bug fix in here: it looks like the CFI annotations were wrong if CONFIG_AUDITSYSCALL=n. Testers beware: on Xen, SYSENTER with NT set turns into a GPF. I haven't touched anything on 32-bit kernels. The syscall mask change comes from a variant of this patch by Anish Bhatt. Note to stable maintainers: there is no known security issue here. A misguided program can set NT and cause the kernel to try and fail to deliver SIGSEGV, crashing the program. This patch fixes Far Cry on Wine: https://bugs.winehq.org/show_bug.cgi?id=33275Reported-by:
Anish Bhatt <anish@chelsio.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Chao Yu authored
commit 35425ea2 upstream. Christopher Head 2014-06-28 05:26:20 UTC described: "I tried to reproduce this on 3.12.21. Instead, when I do "echo hello > foo" in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61 PGD d7840067 PUD b2c3c067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: nvidia(PO) CPU: 3 PID: 3566 Comm: bash Tainted: P O 3.12.21-gentoo-r1 #2 Hardware name: ASUSTek Computer Inc. G60JX/G60JX, BIOS 206 03/15/2010 task: ffff8801948944c0 ti: ffff8800bad70000 task.ti: ffff8800bad70000 RIP: 0010:[<ffffffff8110eb39>] [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61 RSP: 0018:ffff8800bad71c10 EFLAGS: 00010246 RAX: 00000000000181a4 RBX: ffff880198648480 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffff880172010450 RDI: 0000000000000000 RBP: ffff880198490e40 R08: 0000000000000000 R09: 0000000000000000 R10: ffff880172010450 R11: ffffea0002c51e80 R12: 0000000000002000 R13: 000000000000001a R14: 0000000000000000 R15: ffff880198490e40 FS: 00007ff224caa700(0000) GS:ffff88019fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000bb07f000 CR4: 00000000000007e0 Stack: ffffffff811826e8 ffff8800a39d8000 0000000000000000 000000000000001a ffff8800a01d0000 ffff8800a39d8000 ffffffff81185fd5 ffffffff81082c2c 00000001a39d8000 53d0abbc98490e40 0000000000000037 ffff8800a39d8220 Call Trace: [<ffffffff811826e8>] ? ecryptfs_setxattr+0x40/0x52 [<ffffffff81185fd5>] ? ecryptfs_write_metadata+0x1b3/0x223 [<ffffffff81082c2c>] ? should_resched+0x5/0x23 [<ffffffff8118322b>] ? ecryptfs_initialize_file+0xaf/0xd4 [<ffffffff81183344>] ? ecryptfs_create+0xf4/0x142 [<ffffffff810f8c0d>] ? vfs_create+0x48/0x71 [<ffffffff810f9c86>] ? do_last.isra.68+0x559/0x952 [<ffffffff810f7ce7>] ? link_path_walk+0xbd/0x458 [<ffffffff810fa2a3>] ? path_openat+0x224/0x472 [<ffffffff810fa7bd>] ? do_filp_open+0x2b/0x6f [<ffffffff81103606>] ? __alloc_fd+0xd6/0xe7 [<ffffffff810ee6ab>] ? do_sys_open+0x65/0xe9 [<ffffffff8157d022>] ? system_call_fastpath+0x16/0x1b RIP [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61 RSP <ffff8800bad71c10> CR2: 0000000000000000 ---[ end trace df9dba5f1ddb8565 ]---" If we create a file when we mount with ecryptfs_xattr_metadata option, we will encounter a crash in this path: ->ecryptfs_create ->ecryptfs_initialize_file ->ecryptfs_write_metadata ->ecryptfs_write_metadata_to_xattr ->ecryptfs_setxattr ->fsstack_copy_attr_all It's because our dentry->d_inode used in fsstack_copy_attr_all is NULL, and it will be initialized when ecryptfs_initialize_file finish. So we should skip copying attr from lower inode when the value of ->d_inode is invalid. Signed-off-by:
Chao Yu <chao2.yu@samsung.com> Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
-
Alexey Khoroshilov authored
commit 56ec16cb upstream. If cn_add_callback() fails in dm_ulog_tfr_init(), it does not deallocate prealloced memory but calls cn_del_callback(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Reviewed-by:
Jonathan Brassow <jbrassow@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit 0e825862 upstream. When __scan frees the required number of buffer entries that the shrinker requested (nr_to_scan becomes zero) it must return. Before this fix the __scan code exited only the inner loop and continued in the outer loop -- which could result in reduced performance due to extra buffers being freed (e.g. unnecessarily evicted thinp metadata needing to be synchronously re-read into bufio's cache). Also, move dm_bufio_cond_resched to __scan's inner loop, so that iterating the bufio client's lru lists doesn't result in scheduling latency. Reported-by:
Joe Thornber <thornber@redhat.com> Signed-off-by:
-
Joe Thornber authored
commit eb76faf5 upstream. The 'last_accessed' member of the dm_buffer structure was only set when the the buffer was created. This led to each buffer being discarded after dm_bufio_max_age time even if it was used recently. In practice this resulted in all thinp metadata being evicted soon after being read -- this is particularly problematic for metadata intensive workloads like multithreaded small random IO. 'last_accessed' is now updated each time the buffer is moved to the head of the LRU list, so the buffer is now properly discarded if it was not used in dm_bufio_max_age time. Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
-
Dmitry Lavnikevich authored
commit 31d9f8fa upstream. Current caching implementation during regcache_sync() call bypasses all register writes of values that are already known as default (regmap reg_defaults). Same time in TLV320AIC3x codecs register 5 (AIC3X_PLL_PROGC_REG) write should be immediately followed by register 6 write (AIC3X_PLL_PROGD_REG) even if it was not changed. Otherwise both registers will not be written. This brings to issue that appears particulary in case of 44.1kHz playback with 19.2MHz master clock. In this case AIC3X_PLL_PROGC_REG is 0x6e while AIC3X_PLL_PROGD_REG is 0x0 (same as register default). Thus AIC3X_PLL_PROGC_REG also remains not written and we get wrong playback speed. In this patch snd_soc_read() is used to get cached pll values and snd_soc_write() (unlike regcache_sync() this function doesn't bypasses hardware default values) to write them to registers. Signed-off-by:
Dmitry Lavnikevich <d.lavnikevich@sam-solutions.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit e4dc601b upstream. hwreg_present() and hwreg_write() temporarily change the VBR register to another vector table. This table contains a valid bus error handler only, all other entries point to arbitrary addresses. If an interrupt comes in while the temporary table is active, the processor will start executing at such an arbitrary address, and the kernel will crash. While most callers run early, before interrupts are enabled, or explicitly disable interrupts, Finn Thain pointed out that macsonic has one callsite that doesn't, causing intermittent boot crashes. There's another unsafe callsite in hilkbd. Fix this for good by disabling and restoring interrupts inside hwreg_present() and hwreg_write(). Explicitly disabling interrupts can be removed from the callsites later. Reported-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Roger Pau Monné authored
commit 61cecca8 upstream. Fix leaking a page when a grant mapping has failed. Signed-off-by:
Roger Pau Monné <roger.pau@citrix.com> Reported-and-Tested-by:
Tao Chen <boby.chen@huawei.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Andy Adamson authored
commit d1f456b0 upstream. Commit 2f60ea6b ("NFSv4: The NFSv4.0 client must send RENEW calls if it holds a delegation") set the NFS4_RENEW_TIMEOUT flag in nfs4_renew_state, and does not put an nfs41_proc_async_sequence call, the NFSv4.1 lease renewal heartbeat call, on the wire to renew the NFSv4.1 state if the flag was not set. The NFS4_RENEW_TIMEOUT flag is set when "now" is after the last renewal (cl_last_renewal) plus the lease time divided by 3. This is arbitrary and sometimes does the following: In normal operation, the only way a future state renewal call is put on the wire is via a call to nfs4_schedule_state_renewal, which schedules a nfs4_renew_state workqueue task. nfs4_renew_state determines if the NFS4_RENEW_TIMEOUT should be set, and the calls nfs41_proc_async_sequence, which only gets sent if the NFS4_RENEW_TIMEOUT flag is set. Then the nfs41_proc_async_sequence rpc_release function schedules another state remewal via nfs4_schedule_state_renewal. Without this change we can get into a state where an application stops accessing the NFSv4.1 share, state renewal calls stop due to the NFS4_RENEW_TIMEOUT flag _not_ being set. The only way to recover from this situation is with a clientid re-establishment, once the application resumes and the server has timed out the lease and so returns NFS4ERR_BAD_SESSION on the subsequent SEQUENCE operation. An example application: open, lock, write a file. sleep for 6 * lease (could be less) ulock, close. In the above example with NFSv4.1 delegations enabled, without this change, there are no OP_SEQUENCE state renewal calls during the sleep, and the clientid is recovered due to lease expiration on the close. This issue does not occur with NFSv4.1 delegations disabled, nor with NFSv4.0, with or without delegations enabled. Signed-off-by:
Andy Adamson <andros@netapp.com> Link: http://lkml.kernel.org/r/1411486536-23401-1-git-send-email-andros@netapp.com Fixes: 2f60ea6b (NFSv4: The NFSv4.0 client must send RENEW calls...) Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Borislav Petkov authored
commit a18c3f16 upstream. The other two interrupt handlers in this driver are shared, except this one. When loading the driver, it fails like this. So make the IRQ line shared. Freescale(R) MPC85xx EDAC driver, (C) 2006 Montavista Software mpc85xx_mc_err_probe: No ECC DIMMs discovered EDAC DEVICE0: Giving out device to module MPC85xx_edac controller mpc85xx_l2_err: DEV mpc85xx_l2_err (INTERRUPT) genirq: Flags mismatch irq 16. 00000000 ([EDAC] L2 err) vs. 00000080 ([EDAC] PCI err) mpc85xx_l2_err_probe: Unable to request irq 16 for MPC85xx L2 err remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'aerdrv' ------------[ cut here ]------------ WARNING: at fs/proc/generic.c:521 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc5-dirty #1 task: ee058000 ti: ee046000 task.ti: ee046000 NIP: c016c0c4 LR: c016c0c4 CTR: c037b51c REGS: ee047c10 TRAP: 0700 Not tainted (3.17.0-rc5-dirty) MSR: 00029000 <CE,EE,ME> CR: 22008022 XER: 20000000 GPR00: c016c0c4 ee047cc0 ee058000 00000053 00029000 00000000 c037c744 00000003 GPR08: c09aab28 c09aab24 c09aab28 00000156 20008028 00000000 c0002ac8 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000139 c0950394 GPR24: c09f0000 ee5585b0 ee047d08 c0a10000 ee047d08 ee15f808 00000002 ee03f660 NIP [c016c0c4] remove_proc_entry LR [c016c0c4] remove_proc_entry Call Trace: remove_proc_entry (unreliable) unregister_irq_proc free_desc irq_free_descs mpc85xx_l2_err_probe platform_drv_probe really_probe __driver_attach bus_for_each_dev bus_add_driver driver_register mpc85xx_mc_init do_one_initcall kernel_init_freeable kernel_init ret_from_kernel_thread Instruction dump: ... Reported-and-tested-by: <lpb_098@163.com> Acked-by:
Johannes Thumshirn <johannes.thumshirn@men.de> Signed-off-by:
Borislav Petkov <bp@suse.de> [ kamal: backport to 3.13-stable: context ] Signed-off-by:
-
Mikulas Patocka authored
commit 5b789da8 upstream. The function bitcpy_rev has a bug that may result in screen corruption. The bug happens under these conditions: * the end of the destination area of a copy operation is aligned on a long word boundary * the end of the source area is not aligned on a long word boundary * we are copying more than one long word In this case, the variable shift is non-zero and the variable first is zero. The statements FB_WRITEL(comp(d0, FB_READL(dst), first), dst) reads the last long word of the destination and writes it back unchanged (because first is zero). Correctly, we should write the variable d0 to the last word of the destination in this case. This patch fixes the bug by introducing and extra test if first is zero. The patch also removes the references to fb_memmove in the code that is commented out because fb_memmove was removed from framebuffer subsystem. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Mikulas Patocka authored
commit f74a289b upstream. The framebuffer code uses the current background color to fill the border when switching consoles, however, this results in inconsistent behavior. For example: - start Midnigh Commander - the border is black - switch to another console and switch back - the border is cyan - type something into the command line in mc - the border is cyan - switch to another console and switch back - the border is black - press F9 to go to menu - the border is black - switch to another console and switch back - the border is dark blue When switching to a console with Midnight Commander, the border is random color that was left selected by the slang subsystem. This patch fixes this inconsistency by always using black as the background color when switching consoles. Signed-off-by:
-
Mike Christie authored
commit a41a9ad3 upstream. Dan Carpenter found a issue where be2iscsi would copy the ip from userspace to the driver buffer before checking the len of the data being copied: http://marc.info/?l=linux-scsi&m=140982651504251&w=2 This patch just has us only copy what we the driver buffer can support. Tested-by:
John Soni Jose <sony.john-n@emulex.com> Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Al Viro authored
commit 6d13f694 upstream. AFAICS, prepend_name() is broken on SMP alpha. Disclaimer: I don't have SMP alpha boxen to reproduce it on. However, it really looks like the race is real. CPU1: d_path() on /mnt/ramfs/<255-character>/foo CPU2: mv /mnt/ramfs/<255-character> /mnt/ramfs/<63-character> CPU2 does d_alloc(), which allocates an external name, stores the name there including terminating NUL, does smp_wmb() and stores its address in dentry->d_name.name. It proceeds to d_add(dentry, NULL) and d_move() old dentry over to that. ->d_name.name value ends up in that dentry. In the meanwhile, CPU1 gets to prepend_name() for that dentry. It fetches ->d_name.name and ->d_name.len; the former ends up pointing to new name (64-byte kmalloc'ed array), the latter - 255 (length of the old name). Nothing to force the ordering there, and normally that would be OK, since we'd run into the terminating NUL and stop. Except that it's alpha, and we'd need a data dependency barrier to guarantee that we see that store of NUL __d_alloc() has done. In a similar situation dentry_cmp() would survive; it does explicit smp_read_barrier_depends() after fetching ->d_name.name. prepend_name() doesn't and it risks walking past the end of kmalloc'ed object and possibly oops due to taking a page fault in kernel mode. Signed-off-by:
-
Bryan O'Donoghue authored
commit 1ede7dcc upstream. Quark X1000 contains two designware derived 8250 serial ports. Each port has a unique PCI configuration space consisting of BAR0:UART BAR1:DMA respectively. Unlike the standard 8250 the register width is 32 bits for RHR,IER etc The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a bitrate of up to about 2.76 megabits per second. This patch enables standard 8250 mode Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Frans Klaver authored
commit dc318756 upstream. If the chosen baud rate is large enough (e.g. 3.5 megabaud), the calculated n values in serial_omap_is_baud_mode16() may become 0. This causes a division by zero when calculating the difference between calculated and desired baud rates. To prevent this, cap the n13 and n16 values on 1. Division by zero in kernel. [<c00132e0>] (unwind_backtrace) from [<c00112ec>] (show_stack+0x10/0x14) [<c00112ec>] (show_stack) from [<c01ed7bc>] (Ldiv0+0x8/0x10) [<c01ed7bc>] (Ldiv0) from [<c023805c>] (serial_omap_baud_is_mode16+0x4c/0x68) [<c023805c>] (serial_omap_baud_is_mode16) from [<c02396b4>] (serial_omap_set_termios+0x90/0x8d8) [<c02396b4>] (serial_omap_set_termios) from [<c0230a0c>] (uart_change_speed+0xa4/0xa8) [<c0230a0c>] (uart_change_speed) from [<c0231798>] (uart_set_termios+0xa0/0x1fc) [<c0231798>] (uart_set_termios) from [<c022bb44>] (tty_set_termios+0x248/0x2c0) [<c022bb44>] (tty_set_termios) from [<c022c17c>] (set_termios+0x248/0x29c) [<c022c17c>] (set_termios) from [<c022c3e4>] (tty_mode_ioctl+0x1c8/0x4e8) [<c022c3e4>] (tty_mode_ioctl) from [<c0227e70>] (tty_ioctl+0xa94/0xb18) [<c0227e70>] (tty_ioctl) from [<c00cf45c>] (do_vfs_ioctl+0x4a0/0x560) [<c00cf45c>] (do_vfs_ioctl) from [<c00cf568>] (SyS_ioctl+0x4c/0x74) [<c00cf568>] (SyS_ioctl) from [<c000e480>] (ret_fast_syscall+0x0/0x30) Signed-off-by:
Frans Klaver <frans.klaver@xsens.com> Signed-off-by:
-
Trond Myklebust authored
commit df817ba3 upstream. The current open/lock state recovery unfortunately does not handle errors such as NFS4ERR_CONN_NOT_BOUND_TO_SESSION correctly. Instead of looping, just proceeds as if the state manager is finished recovering. This patch ensures that we loop back, handle higher priority errors and complete the open/lock state recovery. Signed-off-by:
-
Trond Myklebust authored
commit a4339b7b upstream. If a NFSv4.x server returns NFS4ERR_STALE_CLIENTID in response to a CREATE_SESSION or SETCLIENTID_CONFIRM in order to tell us that it rebooted a second time, then the client will currently take this to mean that it must declare all locks to be stale, and hence ineligible for reboot recovery. RFC3530 and RFC5661 both suggest that the client should instead rely on the server to respond to inelegible open share, lock and delegation reclaim requests with NFS4ERR_NO_GRACE in this situation. Signed-off-by:
-
Ondrej Zary authored
commit 6d8ca28f upstream. Currently, ata_sff_softreset is skipped for controllers with no ctl port. But that also skips ata_sff_dev_classify required for device detection. This means that libata is currently broken on controllers with no ctl port. No device connected: [ 1.872480] pata_isapnp 01:01.02: activated [ 1.889823] scsi2 : pata_isapnp [ 1.890109] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11 [ 6.888110] ata3.01: qc timeout (cmd 0xec) [ 6.888179] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 16.888085] ata3.01: qc timeout (cmd 0xec) [ 16.888147] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 46.888086] ata3.01: qc timeout (cmd 0xec) [ 46.888148] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 51.888100] ata3.00: qc timeout (cmd 0xec) [ 51.888160] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) [ 61.888079] ata3.00: qc timeout (cmd 0xec) [ 61.888141] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) [ 91.888089] ata3.00: qc timeout (cmd 0xec) [ 91.888152] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) ATAPI device connected: [ 1.882061] pata_isapnp 01:01.02: activated [ 1.893430] scsi2 : pata_isapnp [ 1.893719] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11 [ 6.892107] ata3.01: qc timeout (cmd 0xec) [ 6.892171] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 16.892079] ata3.01: qc timeout (cmd 0xec) [ 16.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 46.892079] ata3.01: qc timeout (cmd 0xec) [ 46.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 46.908586] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr [ 46.924570] ata3.00: configured for PIO0 (device error ignored) [ 46.926295] scsi 2:0:0:0: CD-ROM ACER CD-767E/O 1.5X PQ: 0 ANSI: 5 [ 46.984519] sr0: scsi3-mmc drive: 6x/6x xa/form2 tray [ 46.984592] cdrom: Uniform CD-ROM driver Revision: 3.20 So don't skip ata_sff_softreset, just skip the reset part of ata_bus_softreset if the ctl port is not available. This makes IDE port on ES968 behave correctly: No device connected: [ 4.670888] pata_isapnp 01:01.02: activated [ 4.673207] scsi host2: pata_isapnp [ 4.673675] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11 [ 7.081840] Adding 2541652k swap on /dev/sda2. Priority:-1 extents:1 across:2541652k ATAPI device connected: [ 4.704362] pata_isapnp 01:01.02: activated [ 4.706620] scsi host2: pata_isapnp [ 4.706877] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11 [ 4.872782] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr [ 4.888673] ata3.00: configured for PIO0 (device error ignored) [ 4.893984] scsi 2:0:0:0: CD-ROM ACER CD-767E/O 1.5X PQ: 0 ANSI: 5 [ 7.015578] Adding 2541652k swap on /dev/sda2. Priority:-1 extents:1 across:2541652k Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
Dan Williams authored
commit 7bced397 upstream. Per commit "77873803 net_dma: mark broken" net_dma is no longer used and there is no plan to fix it. This is the mechanical removal of bits in CONFIG_NET_DMA ifdef guards. Reverting the remainder of the net_dma induced changes is deferred to subsequent patches. Marked for stable due to Roman's report of a memory leak in dma_pin_iovec_pages(): https://lkml.org/lkml/2014/9/3/177 Cc: Dave Jiang <dave.jiang@intel.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: David Whipple <whipple@securedatainnovations.ch> Cc: Alexander Duyck <alexander.h.duyck@intel.com> Reported-by:
Roman Gushchin <klamm@yandex-team.ru> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Xiubo Li authored
commit d6b41cb0 upstream. Since we cannot make sure the 'val_count' will always be none zero here, and then if it equals to zero, the kmemdup() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the zero check before calling kmemdup(). Signed-off-by:
Xiubo Li <Li.Xiubo@freescale.com> Signed-off-by:
-
