| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Martin Schwidefsky:
"Bug fixes.
Three for our crypto code, two for eBPF, and one memory management fix
to get machines with memory > 8TB working"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/mm: correct return value of pmd_pfn
s390/crypto: fix stckf loop
s390/zcrypt: Fix invalid domain handling during ap module unload
s390/bpf: Fix gcov stack space problem
s390/zcrypt: fixed ap poll timer behavior
s390/bpf: Adjust ALU64_DIV/MOD to match interpreter change
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This batch became slightly large, just because I've been on vacation
for the last two weeks. Nothing to scare much here, all
device-specific fixes, mostly small patches.
Majority of patches are for HD-audio, especially Dell machines. The
rest are small ASoC fixes for various codecs, and a USB-audio quirk.
One PCM fix is included to ease the faulty condition checks in the
case of two periods PCM buffers"
* tag 'sound-4.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Disable widget power-saving for ALC292 & co
ALSA: hda - Reduce verbs by node power-saves
ALSA: sound/atmel/ac97c.c: remove unused variable
ALSA: usb-audio: Add quirk for MS LifeCam Studio
ALSA: pcm: Modify double acknowledged interrupts check condition
ALSA: hda/realtek - ALC292 dock fix for Thinkpad L450
ALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724
ALSA: hda - Fix headset mic and mic-in for a Dell desktop
ASoC: wm8994: correct BCLK DIV 348 to 384
ASoC: wm8960: fix "RINPUT3" audio route error
ASoC: dapm: Modify widget stream name according to prefix
ALSA: hda - Add headset mic quirk for Dell Inspiron 5548
ASoC: rt5645: Fix mask for setting RT5645_DMIC_2_DP_GPIO12 bit
ASoC: rt5645: Add ACPI match ID
ALSA: hda/realtek - Add ALC298 alias name for Dell
ASoC: uda1380: Avoid accessing i2c bus when codec is disabled
ALSA: hda/realtek - Fix typo for ALC286/ALC288
ASoC: mc13783: Fix wrong mask value used in mc13xxx_reg_rmw() calls
ALSA: hda - Add headphone quirk for Lifebook E752
ASoC: davinci-mcasp: Correct pm status check in suspend callback
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
Pull thermal fixes from Zhang Rui:
"Three fixes for Armada (380) and TI (dra7 and OMAP5) thermal soc
drivers"
* 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
thermal: armada: Update Armada 380 thermal sensor coefficients
thermal: ti-soc-thermal: OMAP5: Implement Workaround for Errata i813
thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i814
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull infiniband/rdma fixes from Doug Ledford:
"This should hopefully be the last request for 4.1-rc for the RDMA
stack. It contains some late ocrdma fixes that I'm including because
they are small and self contained. It also contains two bug fixes
that are simple and easily verified.
Summary:
- a number of small, well contained bug fixes for ocrdma driver
- a simple fix for the connection negotiation sequence on IB
- fix for broken AF_IB address on UD queue pair support"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
IB/cma: Fix broken AF_IB UD support
ib/cm: Change reject message type when destroying cm_id
RDMA/ocrdma: Update ocrdma version number
RDMA/ocrdma: Fail connection for MTU lesser than 512
RDMA/ocrdma: Fix dmac resolution for link local address
RDMA/ocrdma: Prevent allocation of DPP PDs if FW doesnt support it
RDMA/ocrdma: Fix the request length for RDMA_QUERY_QP mailbox command to FW.
RDMA/ocrdma: Use VID 0 if PFC is enabled and vlan is not configured
RDMA/ocrdma: Fix QP state transition in destroy_qp
RDMA/ocrdma: Report EQ full fatal error
RDMA/ocrdma: Fix EQ destroy failure during driver unload
|
|
Pull MMC fix from Ulf Hansson:
"One more mmc fix intended for v4.1 rc5:
MMC host:
- atmel-mci: fix bad variable type for clkdiv"
* tag 'mmc-4.1-rc3' of git://git.linaro.org/people/ulf.hansson/mmc:
mmc: atmel-mci: fix bad variable type for clkdiv
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
Pull HID fixes from Jiri Kosina:
"Bugfixes for HID subsystem that should go in 4.1. Important
highlights:
- the patch that extended support for HID++ protocol for TK820
touchpad turns out to be causing regressions due to firmware
issues; patch reverting back to basic support from Benjamin
Tissoires
- Wacom driver can oops for devices that report non-touch data on
touch interfaces. Fix from Ping Cheng
- gpiolib is not mandatory for i2c-hid, so the driver shouldn't fail
if gpiolib is not enabled. Fix from Mika Westerberg"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: wacom: fix an Oops caused by wacom_wac_finger_count_touches
HID: usbhid: Add HID_QUIRK_NOGET for Aten DVI KVM switch
HID: hid-sensor-hub: Fix debug lock warning
Revert "HID: logitech-hidpp: support combo keyboard touchpad TK820"
HID: i2c-hid: Do not fail probing if gpiolib is not enabled
|
|
Pull crypto fix from Herbert Xu:
"This fixes a the crash in the newly added algif_aead interface when it
tries to link SG lists"
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: algif_aead - fix invalid sgl linking
|
|
Wait a little bit longer, 50mS instead of 20mS, until the driver starts
polling for pen-up. The problematic behavior before this patch is applied
is as follows. The behavior was observed on the STMPE610QTR controller.
Upon a physical pen-down event, the touchscreen reports one set of x-y-p
coordinates and a pen-down event. After that, the pen-up polling is
triggered and since the controller is not ready yet, the polling mistakenly
detects a pen-up event while the physical state is still such that the pen
is down on the touch surface.
The pen-up handling flushes the controller FIFO, so after that, all the
samples in the controller are discarded. The controller becomes ready
shortly after this bogus pen-up handling and does generate again a pen-down
interrupt. This time, the controller contains x-y-p samples which all read
as zero. Since pressure value is zero, this set of samples is effectively
ignored by userland.
In the end, the driver just bounces between pen-down and bogus pen-up
handling, generating no useful results. Fix this by giving the controller a
bit more time before polling it for pen-up.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Use msecs_to_jiffies(20) instead of plain (HZ / 50), as the former is much
more explicit about it's behavior. We want to schedule the task 20 mS from
now, so make it explicit in the code.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Michael Turquette:
"The first set of clk fixes for 4.1 are all driver bugs, with the
exception of a single locking fix in the core code.
All driver fixes are for code that was merged recently. The Samsung
stuff is mostly fixes around suspend/resume, the Qualcomm fixes are
for invalid hardware configuration data and the Silicon Labs patches
are fixes following their move away from platform_data to Device Tree"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: si5351: Do not pass struct clk in platform_data
clk: si5351: Mention clock-names in the binding documentation
clk: add missing lock when call clk_core_enable in clk_set_parent
clk: exynos5420: Restore GATE_BUS_TOP on suspend
clk: qcom: Fix MSM8916 gfx3d_clk_src configuration
clk: qcom: Fix MSM8916 venus divider value
clk: exynos5433: Fix wrong PMS value of exynos5433_pll_rates
clk: exynos5433: Fix wrong parent clock of sclk_apollo clock
clk: exynos5433: Fix CLK_PCLK_MONOTONIC_CNT clk register assignment
clk: exynos5433: Fix wrong offset of PCLK_MSCL_SECURE_SMMU_JPEG
clk: Use CONFIG_ARCH_EXYNOS instead of CONFIG_ARCH_EXYNOS5433
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixlet from Guenter Roeck:
"Update location of Jean Delvare's hwmon quilt tree"
* tag 'hwmon-for-linus-v4.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: Update the location of my quilt tree
|
|
Joydev is currently thinking some absolute mice are joystick, and that
messes up games in VMware guests, as the cursor typically gets stuck in
the top left corner.
Try to detect the event signature of a VMmouse input device and back off
for such devices. We're still incorrectly detecting, for example, the
VMware absolute USB mouse as a joystick, but adding an event signature
matching also that device would be considerably more risky, so defer that
to a later merge window.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Vijay reported that a loop as simple as ...
while true; do
tc qdisc add dev foo root handle 1: prio
tc filter add dev foo parent 1: u32 match u32 0 0 flowid 1
tc qdisc del dev foo root
rmmod cls_u32
done
... will panic the kernel. Moreover, he bisected the change
apparently introducing it to 78fd1d0ab072 ("netlink: Re-add
locking to netlink_lookup() and seq walker").
The removal of synchronize_net() from the netlink socket
triggering the qdisc to be removed, seems to have uncovered
an RCU resp. module reference count race from the tc API.
Given that RCU conversion was done after e341694e3eb5 ("netlink:
Convert netlink_lookup() to use RCU protected hash table")
which added the synchronize_net() originally, occasion of
hitting the bug was less likely (not impossible though):
When qdiscs that i) support attaching classifiers and,
ii) have at least one of them attached, get deleted, they
invoke tcf_destroy_chain(), and thus call into ->destroy()
handler from a classifier module.
After RCU conversion, all classifier that have an internal
prio list, unlink them and initiate freeing via call_rcu()
deferral.
Meanhile, tcf_destroy() releases already reference to the
tp->ops->owner module before the queued RCU callback handler
has been invoked.
Subsequent rmmod on the classifier module is then not prevented
since all module references are already dropped.
By the time, the kernel invokes the RCU callback handler from
the module, that function address is then invalid.
One way to fix it would be to add an rcu_barrier() to
unregister_tcf_proto_ops() to wait for all pending call_rcu()s
to complete.
synchronize_rcu() is not appropriate as under heavy RCU
callback load, registered call_rcu()s could be deferred
longer than a grace period. In case we don't have any pending
call_rcu()s, the barrier is allowed to return immediately.
Since we came here via unregister_tcf_proto_ops(), there
are no users of a given classifier anymore. Further nested
call_rcu()s pointing into the module space are not being
done anywhere.
Only cls_bpf_delete_prog() may schedule a work item, to
unlock pages eventually, but that is not in the range/context
of cls_bpf anymore.
Fixes: 25d8c0d55f24 ("net: rcu-ify tcf_proto")
Fixes: 9888faefe132 ("net: sched: cls_basic use RCU")
Reported-by: Vijay Subramanian <subramanian.vijay@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Tested-by: Vijay Subramanian <subramanian.vijay@gmail.com>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
qos_seq points (to a struct) inside the command response data.
Make sure to free the response only after qos_seq is not
needed anymore.
Reported-by: Heng Luo <heng.luo@intel.com>
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
If the device is reset during suspend with net-detect enabled, we
leave the net-detect information dangling and this causes the next
suspend to fail with a warning:
[21795.351010] WARNING: at /root/iwlwifi/iwlwifi-stack-dev/drivers/net/wireless/iwlwifi/mvm/d3.c:989 __iwl_mvm_suspend.isra.6+0x2be/0x460 [iwlmvm]()
[21795.353253] Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [...]
[21795.366168] CPU: 1 PID: 3645 Comm: bash Tainted: G O 3.10.29-dev #1
[21795.368785] Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012
[21795.371441] f8ec6748 f8ec6748 e51f3ce8 c168aa62 e51f3d10 c103a824 c1871238 f8ec6748
[21795.374228] 000003dd f8eb982e f8eb982e 00000000 c3408ed4 c41edbbc e51f3d20 c103a862
[21795.377006] 00000009 00000000 e51f3da8 f8eb982e c41ee3dc 00000004 e7970000 e51f3d74
[21795.379792] Call Trace:
[21795.382461] [<c168aa62>] dump_stack+0x16/0x18
[21795.385133] [<c103a824>] warn_slowpath_common+0x64/0x80
[21795.387803] [<f8eb982e>] ? __iwl_mvm_suspend.isra.6+0x2be/0x460 [iwlmvm]
[21795.390485] [<f8eb982e>] ? __iwl_mvm_suspend.isra.6+0x2be/0x460 [iwlmvm]
[21795.393124] [<c103a862>] warn_slowpath_null+0x22/0x30
[21795.395787] [<f8eb982e>] __iwl_mvm_suspend.isra.6+0x2be/0x460 [iwlmvm]
[21795.398464] [<f8eb9d7c>] iwl_mvm_suspend+0xec/0x140 [iwlmvm]
[21795.401127] [<c104be11>] ? del_timer_sync+0xa1/0xc0
[21795.403800] [<f8d4107e>] __ieee80211_suspend+0x1de/0xff0 [mac80211]
[21795.406459] [<c168e43d>] ? mutex_lock_nested+0x25d/0x350
[21795.409084] [<c1586b64>] ? rtnl_lock+0x14/0x20
[21795.411685] [<f8cf0076>] ieee80211_suspend+0x16/0x20 [mac80211]
[21795.414318] [<f8c4e014>] wiphy_suspend+0x74/0x710 [cfg80211]
[21795.416916] [<c141e612>] __device_suspend+0x1e2/0x220
[21795.419521] [<f8c4dfa0>] ? addresses_show+0xa0/0xa0 [cfg80211]
[21795.422097] [<c141f997>] dpm_suspend+0x67/0x210
[21795.424661] [<c141fd6f>] dpm_suspend_start+0x4f/0x60
[21795.427219] [<c108d8e0>] suspend_devices_and_enter+0x60/0x480
[21795.429768] [<c168646a>] ? printk+0x4d/0x4f
[21795.432295] [<c108de76>] pm_suspend+0x176/0x210
[21795.434830] [<c108ca5d>] state_store+0x5d/0xb0
[21795.437410] [<c108ca00>] ? wakeup_count_show+0x50/0x50
[21795.439961] [<c13208db>] kobj_attr_store+0x1b/0x30
[21795.442514] [<c11e3a4b>] sysfs_write_file+0xab/0x100
[21795.445088] [<c11e39a0>] ? sysfs_poll+0xa0/0xa0
[21795.447659] [<c1179655>] vfs_write+0xa5/0x1c0
[21795.450212] [<c1179af7>] SyS_write+0x57/0xa0
[21795.452699] [<c1699ec1>] sysenter_do_call+0x12/0x32
[21795.455146] ---[ end trace faf5321baba2bfdb ]---
To fix this, call the iwl_mvm_free_nd() function in case of any error
during resume. Additionally, rename the "out_unlock" label to err to
make it clearer that it's only called in error conditions.
Cc: stable@vger.kernel.org [3.19+]
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The __iwl_mvm_resume() function always returns 1, which causes
mac80211 to do a reconfig with IEEE80211_RECONFIG_TYPE_RESTART. This
type of reconfig calls iwl_mvm_restart_complete(), where we unref the
IWL_MVM_REF_UCODE_DOWN, so we should always take the reference in this
case.
This prevents this kind of warning from happening:
[40026.103025] WARNING: at /root/iwlwifi/iwlwifi-stack-dev/drivers/net/wireless/iwlwifi/mvm/mac80211.c:236 iwl_mvm_unref+0xc9/0xd0 [iwlmvm]()
[40026.105145] Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) ctr ccm arc4 autofs4 snd_hda_codec_hdmi snd_hda_codec_idt joydev coretemp kvm_intel kvm aesni_intel ablk_helper cryptd lrw aes_i586 snd_hda_intel xts snd_hda_codec gf128mul snd_hwdep snd_pcm snd_seq_midi dell_wmi snd_rawmidi sparse_keymap snd_seq_midi_event snd_seq uvcvideo dell_laptop videobuf2_core dcdbas microcode videodev psmouse snd_timer videobuf2_vmalloc videobuf2_memops serio_raw snd_seq_device btusb i915 snd bluetooth lpc_ich drm_kms_helper soundcore snd_page_alloc drm i2c_algo_bit wmi parport_pc ppdev video binfmt_misc rpcsec_gss_krb5 nfsd mac_hid nfs_acl nfsv4 auth_rpcgss nfs fscache lockd sunrpc msdos lp parport sdhci_pci sdhci ahci libahci e1000e mmc_core ptp pps_core [last unloaded: compat]
[40026.117640] CPU: 2 PID: 3827 Comm: bash Tainted: G W O 3.10.29-dev #1
[40026.120216] Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012
[40026.122815] f8effd18 f8effd18 e740fd18 c168aa62 e740fd40 c103a824 c1871238 f8effd18
[40026.125527] 000000ec f8ec79c9 f8ec79c9 d5d29ba4 d5d2a20c 00000000 e740fd50 c103a862
[40026.128209] 00000009 00000000 e740fd7c f8ec79c9 f1c591c4 00000400 00000000 f8efb490
[40026.130886] Call Trace:
[40026.133506] [<c168aa62>] dump_stack+0x16/0x18
[40026.136115] [<c103a824>] warn_slowpath_common+0x64/0x80
[40026.138727] [<f8ec79c9>] ? iwl_mvm_unref+0xc9/0xd0 [iwlmvm]
[40026.141319] [<f8ec79c9>] ? iwl_mvm_unref+0xc9/0xd0 [iwlmvm]
[40026.143881] [<c103a862>] warn_slowpath_null+0x22/0x30
[40026.146453] [<f8ec79c9>] iwl_mvm_unref+0xc9/0xd0 [iwlmvm]
[40026.149030] [<f8ec7a4d>] iwl_mvm_mac_reconfig_complete+0x7d/0x210 [iwlmvm]
[40026.151645] [<f8b74b20>] ? ftrace_raw_event_drv_reconfig_complete+0xc0/0xe0 [mac80211]
[40026.154291] [<f8b6769e>] ieee80211_reconfig+0x28e/0x2620 [mac80211]
[40026.156920] [<c10ef0ea>] ? ring_buffer_unlock_commit+0xba/0x100
[40026.159585] [<f8b4a04d>] ieee80211_resume+0x6d/0x80 [mac80211]
[40026.162206] [<f8a79722>] wiphy_resume+0x72/0x260 [cfg80211]
[40026.164799] [<c141e2e7>] ? device_resume+0x57/0x150
[40026.167425] [<f8a796b0>] ? wiphy_suspend+0x710/0x710 [cfg80211]
[40026.170075] [<c141e26e>] dpm_run_callback+0x2e/0x50
[40026.172695] [<c141e321>] device_resume+0x91/0x150
[40026.175334] [<c141f636>] dpm_resume+0xf6/0x200
[40026.177922] [<c141f920>] dpm_resume_end+0x10/0x20
[40026.180489] [<c108d9f7>] suspend_devices_and_enter+0x177/0x480
[40026.183037] [<c168646a>] ? printk+0x4d/0x4f
[40026.185559] [<c108de76>] pm_suspend+0x176/0x210
[40026.188065] [<c108ca5d>] state_store+0x5d/0xb0
[40026.190581] [<c108ca00>] ? wakeup_count_show+0x50/0x50
[40026.193052] [<c13208db>] kobj_attr_store+0x1b/0x30
[40026.195608] [<c11e3a4b>] sysfs_write_file+0xab/0x100
[40026.198055] [<c11e39a0>] ? sysfs_poll+0xa0/0xa0
[40026.200469] [<c1179655>] vfs_write+0xa5/0x1c0
[40026.202893] [<c1179af7>] SyS_write+0x57/0xa0
[40026.205245] [<c1699ec1>] sysenter_do_call+0x12/0x32
[40026.207619] ---[ end trace db1d5a72a0381b0a ]---
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: EliadX Peller <eliad@wizery.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
There are buses that can't handle ASYNC command without
copying them. Duplicate the host command instead.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Take the MAC address from the OTP even if one is present in
the NVM, if that MAC address happens to be a reserved one.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
fw_status is the only pointer pointing to a block of memory
allocated above and should be freed after use.
Note: this come from Klockwork static analyzer.
Cc: stable@vger.kernel.org [3.19+]
Fixes: 2021a89d7b8a ("iwlwifi: mvm: treat netdetect wake up separately")
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
That atom table does not check these bits. Fixes aux
regressions on some boards.
Reported-by: Malte Schröder <malte@tnxip.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Retry the dpcd fetch several times. Some eDP panels
fail several times before the fetch is successful.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73530
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
The index of ->planes[] array (3rd parameter) cannot be equal to MAX_PLANE.
This looks like a typo that is now fixed.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Evaluating "&mddev->disks" is simple pointer arithmetic, so
it does not need 'rcu' annotations - no dereferencing is happening.
Also enhance the comment to explain that 'rdev' in that case
is not actually a pointer to an rdev.
Reported-by: Patrick Marlier <patrick.marlier@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
The variable "sector" in "raid0_make_request()" was improperly updated
by a call to "sector_div()" which modifies its first argument in place.
Commit 47d68979cc968535cb87f3e5f2e6a3533ea48fbd restored this variable
after the call for later re-use. Unfortunetly the restore was done after
the referenced variable "bio" was advanced. This lead to the original
value and the restored value being different. Here we move this line to
the proper place.
One observed side effect of this bug was discarding a file though
unlinking would cause an unrelated file's contents to be discarded.
Signed-off-by: NeilBrown <neilb@suse.de>
Fixes: 47d68979cc96 ("md/raid0: fix bug with chunksize not a power of 2.")
Cc: stable@vger.kernel.org (any that received above backport)
URL: https://bugzilla.kernel.org/show_bug.cgi?id=98501
|
|
ops_run_reconstruct6() doesn't correctly chain asyn operations. The tx returned
by async_gen_syndrome should be added as the dependent tx of next stripe.
The issue is introduced by commit 59fc630b8b5f9f21c8ce3ba153341c107dce1b0c
RAID5: batch adjacent full stripe write
Reported-and-tested-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
The vmmouse Kconfig help text was referring to an incorrect user-space
driver version. Fix this.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
On v7 touchpads sometimes when 2 fingers are moved down on the touchpad
until they "fall of" the touchpad, the second touch will report 0 for y
(max y really since the y axis is inverted) and max x as coordinates,
rather then reporting 0, 0 as is expected for a non touching finger.
This commit detects this and treats these touches as non touching.
See the evemu-recording here:
https://bugzilla.redhat.com/attachment.cgi?id=1025058
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1221200
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Merge "Few minimal omap device tree fixes for v4.1-rc series" from Tony Lindgren:
- Disable BeagleBone black RTC-only sleep mode because of hardare
related issues
- Fix NAND on Devkit8000
- Fix WLAN interrupt line on AM335x EVM-SK
* tag 'omap-for-v4.1/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: Fix WLAN interrupt line for AM335x EVM-SK
ARM: dts: omap3-devkit8000: Fix NAND DT node
ARM: dts: am335x-boneblack: disable RTC-only sleep
|
|
Support for using UD and AF_IB is currently broken. The
IB_CM_SIDR_REQ_RECEIVED message is not handled properly in
cma_save_net_info() and we end up falling into code that will try and
process the request as ipv4/ipv6, which will end up failing.
The resolution is to add a check for the SIDR_REQ and call
cma_save_ib_info() with a NULL path record. Change cma_save_ib_info()
to copy the src sib info from the listen_id when the path record is NULL.
Reported-by: Hari Shankar <Hari.Shankar@netapp.com>
Signed-off-by: Matt Finlay <matt@mellanox.com>
Acked-by: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
|
|
When allocating a device table, if the requested allocation is smaller
than the default granule size of the ITS then, we need to round up to
the default size.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
[ stuart: Added comments and massaged changelog ]
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
Reviewed-by: Marc Zygnier <marc.zyngier@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <jason@lakedaemon.net>
Link: http://lkml.kernel.org/r/1432134795-661-1-git-send-email-stuart.yoder@freescale.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
This patch fixes a race condition that occurs when connecting
to a NT 3.51 host without specifying a NetBIOS name.
In that case a RFC1002_NEGATIVE_SESSION_RESPONSE is received
and the SMB negotiation is reattempted, but under some conditions
it leads SendReceive() to hang forever while waiting for srv_mutex.
This, in turn, sets the calling process to an uninterruptible sleep
state and makes it unkillable.
The solution is to unlock the srv_mutex acquired in the demux
thread *before* going to sleep (after the reconnect error) and
before reattempting the connection.
|
|
Garbled characters happen by using surrogate pair for filename.
(replace each 1 character to ??)
[Steps to Reproduce for bug]
client# touch $(echo -e '\xf0\x9d\x9f\xa3')
client# touch $(echo -e '\xf0\x9d\x9f\xa4')
client# ls -li
You see same inode number, same filename(=?? and ??) .
Fix the bug about these functions do not consider about surrogate pair (and IVS).
cifs_utf16_bytes()
cifs_mapchar()
cifs_from_utf16()
cifsConvertToUTF16()
Reported-by: Nakajima Akira <nakajima.akira@nttcom.co.jp>
Signed-off-by: Nakajima Akira <nakajima.akira@nttcom.co.jp>
Signed-off-by: Steve French <smfrench@gmail.com>
|
|
posix_lock_file_wait may fail under certain circumstances, and its result is
usually checked/returned. But given the complexity of cifs, I'm not sure if
the result is intentially left unchecked and always expected to succeed.
Signed-off-by: Chengyu Song <csong84@gatech.edu>
Acked-by: Jeff Layton <jeff.layton@primarydata.com>
Signed-off-by: Steve French <smfrench@gmail.com>
|
|
When you refer file directly on cifs client,
(e.g. ls -li <filename>, cd <dir>, stat <filename>)
the function return old inode number and filetype from old inode cache,
though server has different inode number or filetype.
When server is Windows, cifs client has same problem.
When Server is Windows
, This patch fixes bug in different filetype,
but does not fix bug in different inode number.
Because QUERY_PATH_INFO response by Windows does not include inode number(Index Number) .
BUG INFO
https://bugzilla.kernel.org/show_bug.cgi?id=90021
https://bugzilla.kernel.org/show_bug.cgi?id=90031
Reported-by: Nakajima Akira <nakajima.akira@nttcom.co.jp>
Signed-off-by: Nakajima Akira <nakajima.akira@nttcom.co.jp>
Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <smfrench@gmail.com>
|
|
Commit 2f0810880f082fa8ba66ab2c33b02e4ff9770a5e changed
btrfs_set_block_group_ro to avoid trying to allocate new chunks with the
new raid profile during conversion. This fixed failures when there was
no space on the drive to allocate a new chunk, but the metadata
reserves were sufficient to continue the conversion.
But this ended up causing a regression when the drive had plenty of
space to allocate new chunks, mostly because reduce_alloc_profile isn't
using the new raid profile.
Fixing btrfs_reduce_alloc_profile is a bigger patch. For now, do a
partial revert of 2f0810880, and don't error out if we hit ENOSPC.
Signed-off-by: Chris Mason <clm@fb.com>
Tested-by: Dave Sterba <dsterba@suse.cz>
Reported-by: Holger Hoffstaette <holger.hoffstaette@googlemail.com>
|
|
This reverts commit ba9d114ec5578e6e99a4dfa37ff8ae688040fd64.
.. which introduced a regression that prevented all lingering requests
requeued in kick_requests() from ever being sent to the OSDs, resulting
in a lot of missed notifies. In retrospect it's pretty obvious that
r_req_lru_item item in the case of lingering requests can be used not
only for notarget, but also for unsent linkage due to how tightly
actual map and enqueue operations are coupled in __map_request().
The assertion that was being silenced is taken care of in the previous
("libceph: request a new osdmap if lingering request maps to no osd")
commit: by always kicking homeless lingering requests we ensure that
none of them ends up on the notarget list outside of the critical
section guarded by request_mutex.
Cc: stable@vger.kernel.org # 3.18+, needs b0494532214b "libceph: request a new osdmap if lingering request maps to no osd"
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
|
|
This commit does two things. First, if there are any homeless
lingering requests, we now request a new osdmap even if the osdmap that
is being processed brought no changes, i.e. if a given lingering
request turned homeless in one of the previous epochs and remained
homeless in the current epoch. Not doing so leaves us with a stale
osdmap and as a result we may miss our window for reestablishing the
watch and lose notifies.
MON=1 OSD=1:
# cat linger-needmap.sh
#!/bin/bash
rbd create --size 1 test
DEV=$(rbd map test)
ceph osd out 0
rbd map dne/dne # obtain a new osdmap as a side effect (!)
sleep 1
ceph osd in 0
rbd resize --size 2 test
# rbd info test | grep size -> 2M
# blockdev --getsize $DEV -> 1M
N.B.: Not obtaining a new osdmap in between "osd out" and "osd in"
above is enough to make it miss that resize notify, but that is a
bug^Wlimitation of ceph watch/notify v1.
Second, homeless lingering requests are now kicked just like those
lingering requests whose mapping has changed. This is mainly to
recognize that a homeless lingering request makes no sense and to
preserve the invariant that a registered lingering request is not
sitting on any of r_req_lru_item lists. This spares us a WARN_ON,
which commit ba9d114ec557 ("libceph: clear r_req_lru_item in
__unregister_linger_request()") tried to fix the _wrong_ way.
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
|
|
While Sitara AM335x SoCs are very close to OMAP SoCs, the 32-line GPIO
controllers are numbered from 0 on AM335x and from 1 on OMAP. But when
the configuration for the TI WLAN controllers was converted from
platform data to device tree, this detail was overlooked, as 10 boards
were using OMAP with the WL12xx and WL18xx controllers, and only one
was based on AM335x.
This invalid configuration prevents the WL1271 module on the AM335x
EVM-SK from notifying interrupts to the SoC, and breaks the wlan driver.
The DTS must be corrected to use the correct GPIO controller.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add nand-ecc-opt and device-width properties to enable nand support on
Devkit8000.
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Fixes: http://bugs.elinux.org/issues/143
Entering RTC-only sleep is only properly supported on early prototypes series
(pre-A6) of the BeagleBone Black. Since rev (A6A), which include all production
versions, it is not support at due to.
(rev A6) enable of the 3v3b regulator moved from LDO2 to LDO4 (3v3a)
side-effect: 3v3b rail remains on in sleep-mode (also in off-mode when battery-powered)
(rev A6A) am335x vdds supply moved from LDO3 to LDO1
side-effect: vdds remains supplied in sleep-mode
Reported-by: Matthijs van Duin <matthijsvanduin@gmail.com>
Tested-by: Matthijs van Duin <matthijsvanduin@gmail.com>
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Problem reported by: Ted Kim <ted.h.kim@oracle.com>:
We have a case where a Linux system and a non-Linux system are
trying to interoperate. The Linux host is the active side and
starts the connection establishment, but later decides to not go
through with the connection setup and does rdma_destroy_id().
The rdma_destroy_id() eventually works its way down to cm_destroy_id()
in core/cm.c, where a REJ is sent. The non-Linux system
has some trouble recognizing the REJ because of:
A. CM states which can't receive the REJ
B. Some issues about REJ formatting (missing comm ID)
ISSUE A: That part of the spec says, a Consumer Reject REJ can be
sent for a connection abort, but it goes further
and says: can send a REJ message with a "Consumer Reject"
Reason code if they are in a CM state (i.e. REP
Rcvd, MRA(REP) Sent, REQ Rcvd, MRA Sent) that allows
a REJ to be sent (lines 35-38).
Of the states listed there in that sentence, it would
seem to limit the active side to using the Consumer Reject
(for the abort case) in just the REP-Rcvd and MRA-REP-Sent
states. That is basically only after the active side
sees a REP (or alternatively goes down the state transitions
to timeout in which case a Timeout REJ is sent).
As a fix, in cm-destroy-id() move the IB-CM-MRA-REQ-RCVD case
to the same as REQ-SENT. Essentially, make a REJ sent after
getting an MRA on active side a timeout rather than Consumer-
Reject, which is arguably more correct with the CM state
diagrams previous to getting a REP.
Signed-off-by: Ted Kim <ted.h.kim@oracle.com>
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
|
|
Smatch complains because we dereference "ses->server" without checking
some lines earlier inside the call to get_next_mid(ses->server).
fs/cifs/cifssmb.c:4921 CIFSGetDFSRefer()
warn: variable dereferenced before check 'ses->server' (see line 4899)
There is only one caller for this function get_dfs_path() and it always
passes a non-null "ses->server" pointer so this NULL check can be
removed.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steve French <smfrench@gmail.com>
|
|
This is an alternative way of fixing:
commit db9683fb412d ("net: phy: Make sure PHY_RESUMING state change
is always processed")
When the PHY state transitions from PHY_HALTED to PHY_RESUMING, there are
two things we need to do:
1). Re-enable interrupts (and power up the physical link, if powered down)
2). Update the PHY state and net-device based on the link status.
There's no strict reason why #1 has to be done from within the main
phy_state_machine() function. There is a risk that other changes to the
PHY (e.g. setting speed/duplex, which calls phy_start_aneg()) could cause
a subsequent state transition before phy_state_machine() has processed
the PHY_RESUMING state change. This would leave the PHY with interrupts
disabled and/or still in the BMCR_PDOWN/low-power mode.
Moving enabling the interrupts and phy_resume() into phy_start() will
guarantee this work always gets done. As the PHY is already in the HALTED
state and interrupts are disabled, it shouldn't conflict with any work
being done in phy_state_machine(). The downside of this change is that if
the PHY_RESUMING state is ever entered from anywhere else, it'll also have
to repeat this work.
Signed-off-by: Tim Beale <tim.beale@alliedtelesis.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Michal Kubecek says:
====================
IPv6 ECMP route add/replace fixes
(1) When adding a nexthop of a multipath route fails (e.g. because of a
conflict with an existing route), we are supposed to delete nexthops
already added. However, currently we try to also delete all nexthops we
haven't even tried to add yet so that a "ip route add" command can
actually remove pre-existing routes if it fails.
(2) Attempt to replace a multipath route results in a broken siblings
linked list. Following commands (like "ip route del") can then either
follow a link into freed memory or end in an infinite loop (if the slab
object has been reused).
v2: fix an omission in first patch
v3: change the semantics of replace operation to better match IPv4
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When replacing an IPv6 multipath route with "ip route replace", i.e.
NLM_F_CREATE | NLM_F_REPLACE, fib6_add_rt2node() replaces only first
matching route without fixing its siblings, resulting in corrupted
siblings linked list; removing one of the siblings can then end in an
infinite loop.
IPv6 ECMP implementation is a bit different from IPv4 so that route
replacement cannot work in exactly the same way. This should be a
reasonable approximation:
1. If the new route is ECMP-able and there is a matching ECMP-able one
already, replace it and all its siblings (if any).
2. If the new route is ECMP-able and no matching ECMP-able route exists,
replace first matching non-ECMP-able (if any) or just add the new one.
3. If the new route is not ECMP-able, replace first matching
non-ECMP-able route (if any) or add the new route.
We also need to remove the NLM_F_REPLACE flag after replacing old
route(s) by first nexthop of an ECMP route so that each subsequent
nexthop does not replace previous one.
Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If adding a nexthop of an IPv6 multipath route fails, comment in
ip6_route_multipath() says we are going to delete all nexthops already
added. However, current implementation deletes even the routes it
hasn't even tried to add yet. For example, running
ip route add 1234:5678::/64 \
nexthop via fe80::aa dev dummy1 \
nexthop via fe80::bb dev dummy1 \
nexthop via fe80::cc dev dummy1
twice results in removing all routes first command added.
Limit the second (delete) run to nexthops that succeeded in the first
(add) run.
Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
Merge "The i.MX fixes for 4.1, 2nd round" from Shawn Guo:
- Fix i.MX27 FEC register map which overlaps the SCC (Security
Controller) register space.
- Fix i.MX27 DTB build rule which was wrongly controlled by i.MX31
option.
* tag 'imx-fixes-4.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: fix imx27 dtb build rule
ARM: dts: imx27: only map 4 Kbyte for fec registers
|
|
Dan Carpenter pointed out an inconsistent null pointer check
in smb2_hdr_assemble that was pointed out by static checker.
Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: Sachin Prabhu <sprabhu@redhat.com>
CC: Dan Carpenter <dan.carpenter@oracle.com>w
|
|
Recent fix for BCM4704 reboots has to be extended as the same problem
affects Linksys WRT350N v1 (BCM4705).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reported-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Some splats I was seeing:
(a) WARNING: CPU: 1 PID: 0 at /devel/src/linux/net/mac80211/wep.c:102 ieee80211_wep_add_iv
(b) WARNING: CPU: 1 PID: 0 at /devel/src/linux/net/mac80211/wpa.c:73 ieee80211_tx_h_michael_mic_add
(c) WARNING: CPU: 3 PID: 0 at /devel/src/linux/net/mac80211/wpa.c:433 ieee80211_crypto_ccmp_encrypt
I've seen (a) and (b) with ath9k hw crypto and (c)
with ath9k sw crypto. All of them were related to
insufficient skb tailroom and I was able to
trigger these with ping6 program.
AP_VLANs may inherit crypto keys from parent AP.
This wasn't considered and yielded problems in
some setups resulting in inability to transmit
data because mac80211 wouldn't resize skbs when
necessary and subsequently drop some packets due
to insufficient tailroom.
For efficiency purposes don't inspect both AP_VLAN
and AP sdata looking for tailroom counter. Instead
update AP_VLAN tailroom counters whenever their
master AP tailroom counter changes.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
