- 28 5月, 2014 4 次提交
-
-
由 Jean Delvare 提交于
There is no point in calling dev_get_drvdata without a valid device. So checking for dev == NULL is pointless. If such a check is ever needed - which I doubt - the driver should do it before calling dev_get_drvdata. We were returning NULL if dev was NULL, which the caller certainly did not expect anyway, so that was only delaying the crash if the caller is not paying attention. Signed-off-by: NJean Delvare <jdelvare@suse.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jean Delvare 提交于
dev_set_drvdata can no longer fail, so it could return void. All callers have hopefully been updated to no longer check for the return value. Signed-off-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jean Delvare 提交于
So there is no point in checking its return value, which will soon disappear. Signed-off-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jean Delvare 提交于
Having to allocate memory as part of dev_set_drvdata() is a problem because that memory may never get freed if the device itself is not created. So move driver_data back to struct device. This is a partial revert of commit b4028437. Signed-off-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 20 5月, 2014 2 次提交
-
-
由 Shawn Guo 提交于
The commit e783c51c (ahci: imx: software workaround for phy reset issue in resume) calls imx_sata_phy_reset() to reset phy immediately after SATA MPLL is enabled. It seems working fine mostly, but fails in some case as below. ... ahci-imx 2200000.sata: failed to reset phy: -110 ahci-imx: probe of 2200000.sata failed with error -110 After talking to the designer, we learnt that when enabling i.MX6Q SATA MPLL, we need to wait 100us for it to settle down for safety. Add this required delay to fix above failure. Signed-off-by: NShawn Guo <shawn.guo@freescale.com> Tested-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NTejun Heo <tj@kernel.org>
-
由 Gavin Shan 提交于
The incorrect register offset is passed to pci_wait_for_pending(), which is caused by commit 157e876f ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())"). Fixes: 157e876f ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NAlex Williamson <alex.williamson@gmail.com> CC: stable@vger.kernel.org # v3.14+
-
- 18 5月, 2014 1 次提交
-
-
由 Mikulas Patocka 提交于
On each processed XCOPY command, two "kmalloc-512" memory objects are leaked. These represent two allocations of struct xcopy_pt_cmd in target_core_xcopy.c. The reason for the memory leak is that the cmd_kref field is not initialized (thus, it is zero because the allocations were done with kzalloc). When we decrement zero kref in target_put_sess_cmd, the result is not zero, thus target_release_cmd_kref is not called. This patch fixes the bug by moving kref initialization from target_get_sess_cmd to transport_init_se_cmd (this function is called from target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be easily verified that all code that calls target_get_sess_cmd also calls transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce any new problems. Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org # 3.12+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
- 17 5月, 2014 5 次提交
-
-
由 Theodore Ts'o 提交于
Commit ee1de406 ("random: simplify accounting logic") simplified things too much, in that it allows the following to trigger an overflow that results in a BUG_ON crash: dd if=/dev/urandom of=/dev/zero bs=67108707 count=1 Thanks to Peter Zihlstra for discovering the crash, and Hannes Frederic for analyizing the root cause. Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu> Reported-by: NPeter Zijlstra <peterz@infradead.org> Reported-by: NHannes Frederic Sowa <hannes@stressinduktion.org> Cc: Greg Price <price@mit.edu>
-
由 Tuomas Tynkkynen 提交于
The value written to PLLE_AUX was incorrect due to a wrong variable being used. Without this fix SATA does not work. Cc: stable@vger.kernel.org Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com> Tested-by: NMikko Perttunen <mperttunen@nvidia.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Tested-by: NThierry Reding <treding@nvidia.com> Acked-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NMike Turquette <mturquette@linaro.org> [mturquette@linaro.org: improved changelog]
-
由 Jes Sorensen 提交于
wdev->ifdev should be set by .change_virtual_intf(). This solves the problem of WARN() messages on module unload. Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Seems it helps some users, but causes issues for other users: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 So lets drop it for now until we've figured out a better fix. Fixes: 43d94902 (ACPI / video: Add use_native_backlight quirks for more systems) References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 Cc: All applicable <stable@vger.kernel.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Jes Sorensen 提交于
Use a correct pipe type when filling un interrupt urbs. This should finally take care of the WARN() messages on the console when USB urbs are submitted. Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 5月, 2014 9 次提交
-
-
由 Andy Grover 提交于
Just like for pSCSI, if the transport sets get_write_cache, then it is not valid to enable write cache emulation for it. Return an error. see https://bugzilla.redhat.com/show_bug.cgi?id=1082675Reviewed-by: NChris Leech <cleech@redhat.com> Signed-off-by: NAndy Grover <agrover@redhat.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Nicholas Bellinger 提交于
This patch explicitly disables Immediate + Unsolicited Data for ISER connections during login in iscsi_login_zero_tsih_s2() when protection has been enabled for the session by the underlying hardware. This is currently required because protection / signature memory regions (MRs) expect T10 PI to occur on RDMA READs + RDMA WRITEs transfers, and not on a immediate data payload associated with ISCSI_OP_SCSI_CMD, or unsolicited data-out associated with a ISCSI_OP_SCSI_DATA_OUT. v2 changes: - Add TARGET_PROT_DOUT_INSERT check (Sagi) - Add pr_debug noisemaker (Sagi) - Add goto to avoid early return from MRDSL check (nab) Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Nicholas Bellinger 提交于
This patch fixes a free-after-use regression in ft_free_cmd(), where ft_sess_put() is called with cmd->sess after percpu_ida_free() has already released the tag. Fix this bug by saving the ft_sess pointer ahead of percpu_ida_free(), and pass it directly to ft_sess_put(). The regression was originally introduced in v3.13-rc1 commit: commit 5f544cfa Author: Nicholas Bellinger <nab@daterainc.com> Date: Mon Sep 23 12:12:42 2013 -0700 tcm_fc: Convert to per-cpu command map pre-allocation of ft_cmd Reported-by: NJun Wu <jwu@stormojo.com> Cc: Mark Rustad <mark.d.rustad@intel.com> Cc: Robert Love <robert.w.love@intel.com> Cc: <stable@vger.kernel.org> #3.13+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Nicholas Bellinger 提交于
This patch changes an incorrect use of BUG_ON to instead generate a REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code. This case can occur with traditional TCP where a flood of zeros in the data stream can reach this block for what is presumed to be a NOP-OUT with a solicited reply, but without a valid iscsi_cmd pointer. This incorrect BUG_ON was introduced during the v3.11-rc timeframe with the following commit: commit 778de368 Author: Nicholas Bellinger <nab@linux-iscsi.org> Date: Fri Jun 14 16:07:47 2013 -0700 iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling Reported-by: NArshad Hussain <arshad.hussain@calsoftinc.com> Cc: stable@vger.kernel.org # 3.11+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Sagi Grimberg 提交于
When the target is in stop stage, iSER transport initiates RDMA disconnects. The iSER initiator may wish to establish a new connection over the still existing network portal. In this case iSER transport should not accept and resume new RDMA connections. In order to learn that, iscsi_np is added with enabled flag so the iSER transport can check when deciding weather to accept and resume a new connection request. The iscsi_np is enabled after successful transport setup, and disabled before iscsi_np login threads are cleaned up. Signed-off-by: NSagi Grimberg <sagig@mellanox.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Sagi Grimberg 提交于
RDMA CM and iSCSI target flows are asynchronous and completely uncorrelated. Relying on the fact that iscsi_accept_np will be called after CM connection request event and will wait for it is a mistake. When attempting to login to a few targets this flow is racy and unpredictable, but for parallel login to dozens of targets will race and hang every time. The correct synchronizing mechanism in this case is pending on a semaphore rather than a wait_for_event. We keep the pending interruptible for iscsi_np cleanup stage. (Squash patch to remove dead code into parent - nab) Reported-by: NSlava Shwartsman <valyushash@gmail.com> Signed-off-by: NSagi Grimberg <sagig@mellanox.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Sagi Grimberg 提交于
Should be adding list_add_tail($new, $head) and not the other way around. Signed-off-by: NSagi Grimberg <sagig@mellanox.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Andy Grover 提交于
Userspace tools assume if a value is read from configfs, it is valid and will not cause an error if the same value is written back. The only valid value for pi_prot_type for backends not supporting DIF is 0, so allow this particular value to be set without returning an error. Reported-by: NKrzysztof Chojnowski <frirajder@gmail.com> Signed-off-by: NAndy Grover <agrover@redhat.com> Reviewed-by: NSagi Grimberg <sagig@mellanox.com> Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Marcel Apfelbaum 提交于
When a new device is added below a hotplug bridge, the bridge's secondary bus speed and the device's bus speed must match. The shpchp driver previously checked the bridge's *primary* bus speed, not the secondary bus speed. This caused hot-add errors like: shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch Check the secondary bus speed instead. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251 Fixes: 3749c51a ("PCI: Make current and maximum bus speeds part of the PCI core") Signed-off-by: NMarcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> CC: stable@vger.kernel.org # v2.6.34+
-
- 15 5月, 2014 13 次提交
-
-
由 Ville Syrjälä 提交于
On SNB the BIOS provided WM memory latency values seem insufficient to handle high resolution displays. In this particular case the display mode was a 2560x1440@60Hz, which makes the pixel clock 241.5 MHz. It was empirically found that a memory latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec is what the typical BIOS provided values are on IVB systems. Increase the WM memory latency values to at least 1.2 usec on SNB. Hopefully this won't have a significant effect on power consumption. v2: Increase the latency values regardless of the pixel clock Cc: Robert N <crshman@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254Tested-by: NRobert Navarro <crshman@gmail.com> Tested-by: NVitaly Minko <vitaly.minko@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Aaron Lu 提交于
When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491Reported-by: NNico Schottelius <nico-bugzilla.kernel.org@schottelius.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: NAaron Lu <aaron.lu@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
This matches the algorithm used by earlier kernels when selecting the mode for the fbcon. And only if there is no modes at all, do we fall back to using the BIOS configuration. Seamless transition is still preserved (from the BIOS configuration to ours) so long as the BIOS has also chosen what we hope is the native configuration. Reported-by: NKnut Petersen <Knut_Petersen@t-online.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NKnut Petersen <Knut_Petersen@t-online.de> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> [Jani: applied Chris' "Please imagine that I wrote this correctly."] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
There are certain BDW high res eDP machines that regressed due to commit 38aecea0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Mar 3 11:18:10 2014 +0100 drm/i915: reverse dp link param selection, prefer fast over wide again The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at 2.7 Gbps on the affected machines. Link training succeeded for both, but the screen remained blank with the former config. Further investigation showed that 4 lanes at 5.4 Gbps worked also. The root cause for the blank screen using 2 lanes remains unknown, but apparently the driver for a certain other operating system by default uses the max available lanes. Follow suit on Broadwell eDP, for at least until we figure out what is going on. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Tested-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Mike Snitzer 提交于
Commit 3e9f1be1 ("dm mpath: remove process_queued_ios()") did not consistently take the multipath device's spinlock (m->lock) before calling dm_table_run_md_queue_async() -- which takes the q->queue_lock. Found with code inspection using hint from reported lockdep warning. Reported-by: NBart Van Assche <bvanassche@acm.org> Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
由 Joe Thornber 提交于
If the pool runs out of data space, dm-thin can be configured to either error IOs that would trigger provisioning, or hold those IOs until the pool is resized. Unfortunately, holding IOs until the pool is resized can result in a cascade of tasks hitting the hung_task_timeout, which may render the system unavailable. Add a fixed timeout so IOs can only be held for a maximum of 60 seconds. If LVM is going to resize a thin-pool that is out of data space it needs to be prompt about it. Signed-off-by: NJoe Thornber <ejt@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org # 3.14+
-
由 Joe Thornber 提交于
Commit 3e1a0699 ("dm thin: fix out of data space handling") introduced a regression in the metadata commit() method by returning an error if the pool is in PM_OUT_OF_DATA_SPACE mode. This oversight caused a thin device to return errors even if the default queue_if_no_space ENOSPC handling mode is used. Fix commit() to only fail if pool is in PM_READ_ONLY or PM_FAIL mode. Reported-by: qindehua@163.com Signed-off-by: NJoe Thornber <ejt@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org # 3.14+
-
由 Mikulas Patocka 提交于
The DM crypt target used per-cpu structures to hold pointers to a ablkcipher_request structure. The code assumed that the work item keeps executing on a single CPU, so it didn't use synchronization when accessing this structure. If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online, the work item could be moved to another CPU. This causes dm-crypt crashes, like the following, because the code starts using an incorrect ablkcipher_request: smpboot: CPU 7 is now offline BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt] ... Call Trace: [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt] [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0 [<ffffffff81052a28>] ? process_one_work+0x168/0x470 [<ffffffff8105366b>] ? worker_thread+0x10b/0x390 [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290 [<ffffffff81058d9f>] ? kthread+0xaf/0xc0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 Fix this bug by removing the per-cpu definition. The structure ablkcipher_request is accessed via a pointer from convert_context. Consequently, if the work item is rescheduled to a different CPU, the thread still uses the same ablkcipher_request. This change may undermine performance improvements intended by commit c0297721 ("dm crypt: scale to multiple cpus") on select hardware. In practice no performance difference was observed on recent hardware. But regardless, correctness is more important than performance. Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
-
由 Wolfram Sang 提交于
This hardware does not support zero length transfers. Instead, the driver does one (random) byte transfers currently with undefined results for the slaves. We now bail out. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Andy Gross 提交于
This patch corrects the error check on the call to pm_runtime_get_sync. Signed-off-by: NAndy Gross <agross@codeaurora.org> Reviewed-by: NIvan T. Ivanov <iivanov@mm-sol.com> Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Olof Johansson 提交于
Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NDoug Anderson <dianders@chromium.org> Acked-by: NKukjin Kim <kgene.kim@samsung.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Ulf Hansson 提交于
devm_ioremap() returns NULL on error, not an error. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Du, Wenkai 提交于
There have been "i2c_designware 80860F41:00: controller timed out" errors on a number of Baytrail platforms. The issue is caused by incorrect value in Interrupt Mask Register (DW_IC_INTR_MASK) when i2c core is being enabled. This causes call to __i2c_dw_enable() to immediately start the transfer which leads to timeout. There are 3 failure modes observed: 1. Failure in S0 to S3 resume path The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start the first transaction after resuming from system sleep, TX_EMPTY interrupt is already unmasked because of the hardware default. 2. Failure in normal operational path This failure happens rarely and is hard to reproduce. Debug trace showed that DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant TX_EMPTY was unmasked. 3. Failure in S3 to S0 suspend path This failure also happens rarely and is hard to reproduce. Adding debug trace that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR call trace we could conclude TX_EMPTY was unmasked when problem occurred. The patch masks all interrupts before the controller is enabled to resolve the faulty DW_IC_INTR_MASK conditions. Signed-off-by: NWenkai Du <wenkai.du@intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> [wsa: improved the comment and removed typo in commit msg] Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
- 14 5月, 2014 4 次提交
-
-
由 Thomas Petazzoni 提交于
Commit 75b57ecf ('of: Make device nodes kobjects so they show up in sysfs') has turned Device Tree nodes in kobjects and added a sysfs based representation for Device Tree nodes. Since the sysfs logic is only available after the execution of a core_initcall(), the patch took precautions in of_add_property() and of_remove_property() to not do any sysfs related manipulation early in the boot process. However, it forgot to do the same for of_update_property(), which if used early in the boot process (before core_initcalls have been called), tries to call sysfs_remove_bin_file(), and crashes: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at /home/thomas/projets/linux-2.6/fs/kernfs/dir.c:1216 kernfs_remove_by_name_ns+0x80/0x88() kernfs: can not remove '(null)', no directory Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1-00127-g1d7e7b2-dirty #423 [<c0014910>] (unwind_backtrace) from [<c00110ec>] (show_stack+0x10/0x14) [<c00110ec>] (show_stack) from [<c04c84b8>] (dump_stack+0x84/0x94) [<c04c84b8>] (dump_stack) from [<c001d8c0>] (warn_slowpath_common+0x6c/0x88) [<c001d8c0>] (warn_slowpath_common) from [<c001d90c>] (warn_slowpath_fmt+0x30/0x40) [<c001d90c>] (warn_slowpath_fmt) from [<c0104468>] (kernfs_remove_by_name_ns+0x80/0x88) [<c0104468>] (kernfs_remove_by_name_ns) from [<c0394d98>] (of_update_property+0xc0/0xf0) [<c0394d98>] (of_update_property) from [<c0647248>] (mvebu_timer_and_clk_init+0xfc/0x194) [<c0647248>] (mvebu_timer_and_clk_init) from [<c0640934>] (start_kernel+0x218/0x350) [<c0640934>] (start_kernel) from [<00008070>] (0x8070) ---[ end trace 3406ff24bd97382e ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000003c pgd = c0004000 [0000003c] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.15.0-rc1-00127-g1d7e7b2-dirty #423 task: c10ad4d8 ti: c10a2000 task.ti: c10a2000 PC is at kernfs_find_ns+0x8/0xf0 LR is at kernfs_find_and_get_ns+0x30/0x48 pc : [<c0103834>] lr : [<c010394c>] psr: 600001d3 sp : c10a3f34 ip : 00000073 fp : 00000000 r10: 00000000 r9 : cfffc240 r8 : cfdf2980 r7 : cf812c00 r6 : 00000000 r5 : 00000000 r4 : c10b45e0 r3 : c10ad4d8 r2 : 00000000 r1 : cf812c00 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 0000404a DAC: 00000015 Process swapper/0 (pid: 0, stack limit = 0xc10a2240) Stack: (0xc10a3f34 to 0xc10a4000) 3f20: c10b45e0 00000000 00000000 3f40: cf812c00 c010394c 00000063 cf812c00 00000001 cf812c00 cfdf29ac c03932cc 3f60: 00000063 cf812bc0 cfdf29ac cf812c00 ffffffff c03943f8 cfdf2980 c0104468 3f80: cfdf2a04 cfdf2980 cf812bc0 c06634b0 c10aa3c0 c0394da4 c10f74dc cfdf2980 3fa0: cf812bc0 c0647248 c10aa3c0 ffffffff c10de940 c10aa3c0 ffffffff c0640934 3fc0: ffffffff ffffffff c06404ec 00000000 00000000 c06634b0 00000000 10c53c7d 3fe0: c10aa434 c06634ac c10ae4c8 0000406a 414fc091 00008070 00000000 00000000 [<c0103834>] (kernfs_find_ns) from [<00000001>] (0x1) Code: e5c89001 eaffffcf e92d40f0 e1a06002 (e1d023bc) ---[ end trace 3406ff24bd97382f ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! To fix this problem, we simply skip the sysfs related calls in of_update_property(), and rely on of_init() to fix up things when it will be called, exactly as is done in of_add_property() and of_remove_property(). Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Fixes: 75b57ecf ("of: Make device nodes kobjects so they show up in sysfs") Signed-off-by: NGrant Likely <grant.likely@linaro.org>
-
由 Guennadi Liakhovetski 提交于
If a struct contains 64-bit fields, it is aligned on 64-bit boundaries within containing structs in 64-bit compilations. This is the case with struct v4l2_window, which contains pointers and is embedded into struct v4l2_format, and that one is embedded into struct v4l2_create_buffers. Unlike some other structs, used as a part of the kernel ABI as ioctl() arguments, that are packed, these structs aren't packed. This isn't a problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains a bug, that triggers in such 64-bit builds. That code wrongly assumes, that in struct v4l2_create_buffers, struct v4l2_format immediately follows the __u32 memory field, which in fact isn't the case. This bug wasn't visible until now, because until recently hardly any applications used this ioctl() and mostly embedded 32-bit only drivers implemented it. This is changing now with addition of this ioctl() to some USB drivers, e.g. UVC. This patch fixes the bug by copying parts of struct v4l2_create_buffers separately. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com> Cc: stable@vger.kernel.org
-
由 Guennadi Liakhovetski 提交于
Commit 75e2bdad "ov7670: allow configuration of image size, clock speed, and I/O method" uses a wrong index to iterate an array. Apart from being wrong, it also uses an unchecked value from user-space, which can cause access to unmapped memory in the kernel, triggered by a normal desktop user with rights to use V4L2 devices. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: NJonathan Corbet <corbet@lwn.net> Cc: stable@vger.kernel.org Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
-
由 Vikas Chaudhary 提交于
Search for Broadcom specific ibft sign "BIFT" along with other possible values on UEFI This patch is fix for regression introduced in “935a9fee”. https://lkml.org/lkml/2011/12/16/353 This impacts Broadcom CNA for iSCSI Boot on UEFI platform. Signed-off-by: NVikas Chaudhary <vikas.chaudhary@qlogic.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: NMike Christie <michaelc@cs.wisc.edu>
-
- 13 5月, 2014 2 次提交
-
-
由 Dirk Brandewie 提交于
Setting the P state of the core to max at init time is a hold over from early implementation of intel_pstate where intel_pstate disabled cpufreq and loaded VERY early in the boot sequence. This was to ensure that intel_pstate did not affect boot time. This in not needed now that intel_pstate is a cpufreq driver. Removing this covers the case where a CPU has gone through a manual CPU offline/online cycle and the P state is set to MAX on init and the CPU immediately goes idle. Due to HW coordination the P state request on the idle CPU will drag all cores to MAX P state until the load is reevaluated when to core goes non-idle. Reported-by: NPatrick Marlier <patrick.marlier@gmail.com> Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
We need to find a smarter way to switch to 64-bit FADT addresses according to the bug report. This patch reverts Linux to the original behavior. Fixes: 0249ed24 (ACPICA: Add option to favor 32-bit FADT addresses.) References: https://bugzilla.kernel.org/show_bug.cgi?id=74021Reported-and-tested-by: NOswald Buddenhagen <ossi@kde.org> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-