06 Feb, 2015
27 commits
-
commit 47c1ffb2b6b630894e9a16442611c056ab21c057 upstream.
Add two more Fujitsu LIFEBOOK models that also ship with the Elantech
touchpad and don't work with crc_disabled to the quirk list.Signed-off-by: Rainer Koenig
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 8543cf1c247909ce85850ca6e2714adba351d6aa upstream.
LEN0037 found in the Lenovo ThinkPad X1 Carbon 2nd (2014 model)
Reported-and-tested-by: Bjoern Olausson
Signed-off-by: Peter Hutterer
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 34e81ad5f0b60007c95995eb7803da7e00c6c611 upstream.
This patch solves deadlock between clock prepare mutex and regmap mutex reported
by Tomasz Figa in [1] by implementing solution from [2]: "always leave the clock
of the i2c controller in a prepared state".[1] https://lkml.org/lkml/2014/7/2/171
[2] https://lkml.org/lkml/2014/7/2/207On each i2c transfer handled by s3c24xx_i2c_xfer(), clk_prepare_enable() was
called, which calls clk_prepare() then clk_enable(). clk_prepare() takes
prepare_lock mutex before proceeding. Note that i2c transfer functions are
invoked from many places in kernel, typically with some other additional lock
held.It may happen that function on CPU1 (e.g. regmap_update_bits()) has taken a
mutex (i.e. regmap lock mutex) then it attempts i2c communication in order to
proceed (so it needs to obtain clock related prepare_lock mutex during transfer
preparation stage due to clk_prepare() call). At the same time other task on
CPU0 wants to operate on clock (e.g. to (un)prepare clock for some other reason)
so it has taken prepare_lock mutex.CPU0: CPU1:
clk_disable_unused() regulator_disable()
clk_prepare_lock() map->lock(map->lock_arg)
regmap_read() s3c24xx_i2c_xfer()
map->lock(map->lock_arg) clk_prepare_lock()Implemented solution from [2] leaves i2c clock prepared. Preparation is done in
s3c24xx_i2c_probe() function. Without this patch, it is immediately unprepared
by clk_disable_unprepare() call. I've replaced this call with clk_disable() and
I've added clk_unprepare() call in s3c24xx_i2c_remove().The s3c24xx_i2c_xfer() function now uses clk_enable() instead of
clk_prepare_enable() (and clk_disable() instead of clk_unprepare_disable()).Signed-off-by: Paul Osmialowski
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
commit 8a870880bd6f17b7ccef69a6432ab8df8775fcf6 upstream.
Like some other uas devices these devices hang when a report-opcodes scsi
command is send to them.BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1124119
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
commit bf5c4136fa5ce471bdbf4cf59a813e32755fd014 upstream.
It looks like FUA support is broken on JMicron 152d:2566 bridge:
[223159.885704] sd 7:0:0:0: [sdc] Write Protect is off
[223159.885706] sd 7:0:0:0: [sdc] Mode Sense: 47 00 10 08
[223159.885942] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA[223283.691677] sd 7:0:0:0: [sdc]
[223283.691680] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[223283.691681] sd 7:0:0:0: [sdc]
[223283.691682] Sense Key : Illegal Request [current]
[223283.691684] sd 7:0:0:0: [sdc]
[223283.691685] Add. Sense: Invalid field in cdb
[223283.691686] sd 7:0:0:0: [sdc] CDB:
[223283.691687] Write(10): 2a 08 15 d0 83 0d 00 00 01 00
[223283.691690] blk_update_request: critical target error, dev sdc, sector 2927892584This patch adds blacklist flag so that sd will not use FUA
Signed-off-by: Dmitry Nezhevenko
Cc: Phil Dibowitz
Cc: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
commit e5dff0e80463cc3fa236e898ef1491b40be70b19 upstream.
OTG device shall support this device for allowing compliance automated testing.
The modification is derived from Pavankumar and Vijayavardhans' previous work.Signed-off-by: Macpaul Lin
Cc: Pavankumar Kondeti
Cc: Vijayavardhan Vennapusa
Signed-off-by: Greg Kroah-Hartman -
commit ae43e9d05eb4bd324155292f889fbd001c4faea8 upstream.
The comment for rbd_dev_parent_get() said
* We must get the reference before checking for the overlap to
* coordinate properly with zeroing the parent overlap in
* rbd_dev_v2_parent_info() when an image gets flattened. We
* drop it again if there is no overlap.but the "drop it again if there is no overlap" part was missing from
the implementation. This lead to absurd parent_ref values for images
with parent_overlap == 0, as parent_ref was incremented for each
img_request and virtually never decremented.Fix this by leveraging the fact that refresh path calls
rbd_dev_v2_parent_info() under header_rwsem and use it for read in
rbd_dev_parent_get(), instead of messing around with atomics. Get rid
of barriers in rbd_dev_v2_parent_info() while at it - I don't see what
they'd pair with now and I suspect we are in a pretty miserable
situation as far as proper locking goes regardless.Signed-off-by: Ilya Dryomov
Reviewed-by: Josh Durgin
Reviewed-by: Alex Elder
Signed-off-by: Greg Kroah-Hartman -
commit e69b8d414f948c242ad9f3eb2b7e24fba783dbbd upstream.
This effectively reverts the last hunk of 392a9dad7e77 ("rbd: detect
when clone image is flattened").The problem with parent_overlap != 0 condition is that it's possible
and completely valid to have an image with parent_overlap == 0 whose
parent state needs to be cleaned up on unmap. The next commit, which
drops the "clone image now standalone" logic, opens up another window
of opportunity to hit this, but even without it# cat parent-ref.sh
#!/bin/bash
rbd create --image-format 2 --size 1 foo
rbd snap create foo@snap
rbd snap protect foo@snap
rbd clone foo@snap bar
rbd resize --allow-shrink --size 0 bar
rbd resize --size 1 bar
DEV=$(rbd map bar)
rbd unmap $DEVleaves rbd_device/rbd_spec/etc and rbd_client along with ceph_client
hanging around.My thinking behind calling rbd_dev_parent_put() unconditionally is that
there shouldn't be any requests in flight at that point in time as we
are deep into unmap sequence. Hence, even if rbd_dev_unparent() caused
by flatten is delayed by in-flight requests, it will have finished by
the time we reach rbd_dev_unprobe() caused by unmap, thus turning
unconditional rbd_dev_parent_put() into a no-op.Fixes: http://tracker.ceph.com/issues/10352
Signed-off-by: Ilya Dryomov
Reviewed-by: Josh Durgin
Reviewed-by: Alex Elder
Signed-off-by: Greg Kroah-Hartman -
commit 0767e95bb96d7fdddcd590fb809e6975d93aebc5 upstream.
When the last subscriber to a "Through" port has been removed, the
subscribed destination ports might still be active, so it would be
wrong to send "all sounds off" and "reset controller" events to them.
The proper place for such a shutdown would be the closing of the actual
MIDI port (and close_substream() in rawmidi.c already can do this).This also fixes a deadlock when dummy_unuse() tries to send events to
its own port that is already locked because it is being freed.Reported-by: Peter Billam
Signed-off-by: Clemens Ladisch
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit e6eb2eba494d6f99e69ca3c3748cd37a2544ab38 upstream.
The commit 3b8a3c010969 ("powerpc/pseries: Fix endiannes issue in RTAS
call from xmon") was fixing an endianness issue in the call made from
xmon to RTAS.However, as Michael Ellerman noticed, this fix was not complete, the
token value was not byte swapped. This lead to call an unexpected and
most of the time unexisting RTAS function, which is silently ignored by
RTAS.This fix addresses this hole.
Reported-by: Michael Ellerman
Signed-off-by: Laurent Dufour
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit e638642b08c170d2021b706f0b1c4f4ae93d8cbd upstream.
While being in an ERROR_WARNING state, and receiving further
bus error events with error counters still in the ERROR_WARNING
range of 97-127 inclusive, the state handling code erroneously
reverts back to ERROR_ACTIVE.Per the CAN standard, only revert to ERROR_ACTIVE when the
error counters are less than 96.Moreover, in certain Kvaser models, the BUS_ERROR flag is
always set along with undefined bits in the M16C status
register. Thus use bitwise operators instead of full equality
for checking that register against bus errors.Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 14c10c2a1dd8eb8e00b750b521753260befa2789 upstream.
On some x86 laptops, plugging a Kvaser device again after an
unplug makes the firmware always ignore the very first command.
For such a case, provide some room for retries instead of
completely exiting the driver init code.Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 3803fa6977f1de15fda4e8646c8fec97c8045cae upstream.
Send expected argument to the URB completion hander: a CAN
netdevice instead of the network interface private context
`kvaser_usb_net_priv'.This was discovered by having some garbage in the kernel
log in place of the netdevice names: can0 and can1.Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit ded5006667318c06df875609535176bd33f243a1 upstream.
Upon receiving a hardware event with the BUS_RESET flag set,
the driver kills all of its anchored URBs and resets all of
its transmit URB contexts.Unfortunately it does so under the context of URB completion
handler `kvaser_usb_read_bulk_callback()', which is often
called in an atomic context.While the device is flooded with many received error packets,
usb_kill_urb() typically sleeps/reschedules till the transfer
request of each killed URB in question completes, leading to
the sleep in atomic bug. [3]In v2 submission of the original driver patch [1], it was
stated that the URBs kill and tx contexts reset was needed
since we don't receive any tx acknowledgments later and thus
such resources will be locked down forever. Fortunately this
is no longer needed since an earlier bugfix in this patch
series is now applied: all tx URB contexts are reset upon CAN
channel close. [2]Moreover, a BUS_RESET is now treated _exactly_ like a BUS_OFF
event, which is the recommended handling method advised by
the device manufacturer.[1] http://article.gmane.org/gmane.linux.network/239442
http://www.webcitation.org/6Vr2yagAQ[2] can: kvaser_usb: Reset all URB tx contexts upon channel close
889b77f7fd2bcc922493d73a4c51d8a851505815[3] Stacktrace:
[] dump_stack+0x45/0x57
[] __schedule_bug+0x41/0x4f
[] __schedule+0x5f1/0x700
[] ? _raw_spin_unlock_irqrestore+0xa/0x10
[] schedule+0x24/0x70
[] usb_kill_urb+0x65/0xa0
[] ? prepare_to_wait_event+0x110/0x110
[] usb_kill_anchored_urbs+0x48/0x80
[] kvaser_usb_unlink_tx_urbs+0x18/0x50 [kvaser_usb]
[] kvaser_usb_rx_error+0xc0/0x400 [kvaser_usb]
[] ? vprintk_default+0x1a/0x20
[] kvaser_usb_read_bulk_callback+0x4c1/0x5f0 [kvaser_usb]
[] __usb_hcd_giveback_urb+0x5e/0xc0
[] usb_hcd_giveback_urb+0x41/0x110
[] finish_urb+0x98/0x180 [ohci_hcd]
[] ? acct_account_cputime+0x17/0x20
[] ? local_clock+0x15/0x30
[] ohci_work+0x1fb/0x5a0 [ohci_hcd]
[] ? process_backlog+0xb1/0x130
[] ohci_irq+0xeb/0x270 [ohci_hcd]
[] usb_hcd_irq+0x21/0x30
[] handle_irq_event_percpu+0x43/0x120
[] handle_irq_event+0x3d/0x60
[] handle_fasteoi_irq+0x74/0x110
[] handle_irq+0x1d/0x30
[] do_IRQ+0x57/0x100
[] common_interrupt+0x6a/0x6aSigned-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit b07ef35244424cbeda9844198607c7077099c82c upstream.
Commit 6fb1ca92a640 "udf: Fix race between write(2) and close(2)"
changed the condition when preallocation is released. The idea was that
we don't want to release the preallocation for an inode on close when
there are other writeable file descriptors for the inode. However the
condition was written in the opposite way so we released preallocation
only if there were other writeable file descriptors. Fix the problem by
changing the condition properly.Fixes: 6fb1ca92a6409a9d5b0696447cd4997bc9aaf5a2
Reported-by: Fabian Frederick
Signed-off-by: Jan Kara
Signed-off-by: Greg Kroah-Hartman -
commit 20602e34cd33dd452bc1836fa7c9b59978f75db0 upstream.
We should select FSR also to be driven by McBSP, not only FSX.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 7ddfdb5c5a5b51bdd2cb749d8341d763b079d520 upstream.
If asoc_simple_card_probe() fails, asoc_simple_card_unref() may be
called before dev_set_drvdata(), causing a NULL pointer dereference in
asoc_simple_card_unref():Unable to handle kernel NULL pointer dereference at virtual address 000000d4
...
PC is at asoc_simple_card_unref+0x14/0x48
LR is at asoc_simple_card_probe+0x3d4/0x40cThis typically happens because asoc_simple_card_parse_of() returns
-EPROBE_DEFER, but other failure modes are possible.
devm_snd_soc_register_card()/snd_soc_register_card() may fail either
before or after dev_set_drvdata().Pass a snd_soc_card pointer instead of a platform_device pointer to
asoc_simple_card_unref() to fix this.Note that if CONFIG_OF_DYNAMIC=n, of_node_put() is a dummy, and gcc may
optimize away the loop over card->dai_link, never actually dereferencing
card, and thus avoiding the crash...Signed-off-by: Geert Uytterhoeven
Fixes: e512e001dafa54e5 ("ASoC: simple-card: Fix the reference count of device nodes")
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit d3268a40d4b19ff7bee23f52eabbc4e96bb685e8 upstream.
In soc_new_compress() when rtd->dai_link->dynamic is set, we create the pcm
substreams with this call:ret = snd_pcm_new_internal(rtd->card->snd_card, new_name, num,
1, 0, &be_pcm);which passes 0 as capture_count leading to
be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream
being NULL, hence when trying to set rtd a few lines below we get an oops.
Fix by using rtd->dai_link->dpcm_playback and rtd->dai_link->dpcm_capture as
playback_count and capture_count to snd_pcm_new_internal().Signed-off-by: Qais Yousef
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit adc60298c80efef4c2d7a7860b91b450931a7cf8 upstream.
The xDC field should have 5 bit width according to Reference Manual.
Thus this patch fixes it.Signed-off-by: Aurelien BOUIN
Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 3a8e5019846736046c0af9dbee3f921c0456141a upstream.
The DSP programs are listed out of order.
Signed-off-by: Peter Rosin
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 22ee76daddb87f88d2336d1b4737ef27c4f307ac upstream.
wm8960 codec can't support sample rate 11250, it must be 11025.
Signed-off-by: Zidan Wang
Acked-by: Charles Keepax
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 9c145c56d0c8a0b62e48c8d71e055ad0fb2012ba upstream.
The stack guard page error case has long incorrectly caused a SIGBUS
rather than a SIGSEGV, but nobody actually noticed until commit
fee7e49d4514 ("mm: propagate error from stack expansion even for guard
page") because that error case was never actually triggered in any
normal situations.Now that we actually report the error, people noticed the wrong signal
that resulted. So far, only the test suite of libsigsegv seems to have
actually cared, but there are real applications that use libsigsegv, so
let's not wait for any of those to break.Reported-and-tested-by: Takashi Iwai
Tested-by: Jan Engelhardt
Acked-by: Heiko Carstens # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit e262eb9381ad51b5de7a9e762ee773bbd25ce650 upstream.
Fix misspelled define.
Fixes: 33692f27597f ("vm: add VM_FAULT_SIGSEGV handling support")
Signed-off-by: Guenter Roeck
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.
The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
"you should SIGSEGV" error, because the SIGSEGV case was generally
handled by the caller - usually the architecture fault handler.That results in lots of duplication - all the architecture fault
handlers end up doing very similar "look up vma, check permissions, do
retries etc" - but it generally works. However, there are cases where
the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.In particular, when accessing the stack guard page, libsigsegv expects a
SIGSEGV. And it usually got one, because the stack growth is handled by
that duplicated architecture fault handler.However, when the generic VM layer started propagating the error return
from the stack expansion in commit fee7e49d4514 ("mm: propagate error
from stack expansion even for guard page"), that now exposed the
existing VM_FAULT_SIGBUS result to user space. And user space really
expected SIGSEGV, not SIGBUS.To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
duplicate architecture fault handlers about it. They all already have
the code to handle SIGSEGV, so it's about just tying that new return
value to the existing code, but it's all a bit annoying.This is the mindless minimal patch to do this. A more extensive patch
would be to try to gather up the mostly shared fault handling logic into
one generic helper routine, and long-term we really should do that
cleanup.Just from this patch, you can generally see that most architectures just
copied (directly or indirectly) the old x86 way of doing things, but in
the meantime that original x86 model has been improved to hold the VM
semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
"newer" things, so it would be a good idea to bring all those
improvements to the generic case and teach other architectures about
them too.Reported-and-tested-by: Takashi Iwai
Tested-by: Jan Engelhardt
Acked-by: Heiko Carstens # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 67bf9cda4b498b8cea4a40be67a470afe57d2e88 upstream.
The FIFO size is 40 accordingly to the specifications, but this means 0x40,
i.e. 64 bytes. This patch fixes the typo and enables FIFO size autodetection
for Intel MID devices.Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support)
Signed-off-by: Andy Shevchenko
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit d297933cc7fcfbaaf2d37570baac73287bf0357d upstream.
Current code tries to find the highest valid fifo depth by checking the value
it wrote to DW_SPI_TXFLTR. There are a few problems in current code:
1) There is an off-by-one in dws->fifo_len setting because it assumes the latest
register write fails so the latest valid value should be fifo - 1.
2) We know the depth could be from 2 to 256 from HW spec, so it is not necessary
to test fifo == 257. In the case fifo is 257, it means the latest valid
setting is fifo = 256. So after the for loop iteration, we should check
fifo == 2 case instead of fifo == 257 if detecting the FIFO depth fails.
This patch fixes above issues.Signed-off-by: Axel Lin
Reviewed-and-tested-by: Andy Shevchenko
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit d69911a68c865b152a067feaa45e98e6bb0f655b upstream.
Commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
added Perl to the required build environment. This reimplements in
shell the Perl script used to find the size of the kernel with bss and
brk added.Signed-off-by: Kees Cook
Reported-by: Rob Landley
Acked-by: Rob Landley
Cc: Anca Emanuel
Cc: Fengguang Wu
Cc: Junjie Mao
Cc: Kees Cook
Cc: Thomas Gleixner
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
30 Jan, 2015
13 commits
-
commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream.
Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.Even though commit 5d26a105b5a7 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook
Signed-off-by: Mathias Krause
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 4943ba16bbc2db05115707b3ff7b4874e9e3c560 upstream.
This adds the module loading prefix "crypto-" to the template lookup
as well.For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the "crypto-" prefix at every level, correctly rejecting "vfat":net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfatReported-by: Mathias Krause
Signed-off-by: Kees Cook
Acked-by: Mathias Krause
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 175f8e2650f7ca6b33d338be3ccc1c00e89594ea upstream.
In some cases acpi_device_wakeup() may be called to ensure wakeup
power to be off for a given device even though that device's wakeup
GPE has not been enabled so far. It calls acpi_disable_gpe() on a
GPE that's not enabled and this causes ACPICA to return the AE_LIMIT
status code from that call which then is reported as an error by the
ACPICA's debug facilities (if enabled). This may lead to a fair
amount of confusion, so introduce a new ACPI device wakeup flag
to store the wakeup GPE status and avoid disabling wakeup GPEs
that have not been enabled.Reported-and-tested-by: Venkat Raghavulu
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 7e2a38831db4cf082aa8b4997f3cbfe8cb03b669 upstream.
Add a flag that enables match found notification to align with
FW API change.Signed-off-by: David Spinadel
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Greg Kroah-Hartman -
commit dbdd74763f1faf799fbb9ed30423182e92919378 upstream.
This reverts commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46.
This commit broke on x86 PV because entries in the generic SWIOTLB are
indexed using (pseudo-)physical address not DMA address and these are
not the same in a x86 PV guest.Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
Signed-off-by: Greg Kroah-Hartman -
commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream.
The app_tcp_pkt_out() function expects "*diff" to be set and ends up
using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov
for noticing that.Signed-off-by: Dan Carpenter
Acked-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman -
commit 8ca3f5e974f2b4b7f711589f4abff920db36637a upstream.
Commit 5195c14c8b27c ("netfilter: conntrack: fix race in
__nf_conntrack_confirm against get_next_corpse") aimed to resolve the
race condition between the confirmation (packet path) and the flush
command (from control plane). However, it introduced a crash when
several packets race to add a new conntrack, which seems easier to
reproduce when nf_queue is in place.Fix this race, in __nf_conntrack_confirm(), by removing the CT
from unconfirmed list before checking the DYING bit. In case
race occured, re-add the CT to the dying listThis patch also changes the verdict from NF_ACCEPT to NF_DROP when
we lose race. Basically, the confirmation happens for the first packet
that we see in a flow. If you just invoked conntrack -F once (which
should be the common case), then this is likely to be the first packet
of the flow (unless you already called flush anytime soon in the past).
This should be hard to trigger, but better drop this packet, otherwise
we leave things in inconsistent state since the destination will likely
reply to this packet, but it will find no conntrack, unless the origin
retransmits.The change of the verdict has been discussed in:
https://www.marc.info/?l=linux-netdev&m=141588039530056&w=2Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit 62924af247e95de7041a6d6f2d06cdd05152e2dc upstream.
Relax the checking that was introduced in 97840cb ("netfilter:
nfnetlink: fix insufficient validation in nfnetlink_bind") when the
subscription bitmask is used. Existing userspace code code may request
to listen to all of the existing netlink groups by setting an all to one
subscription group bitmask. Netlink already validates subscription via
setsockopt() for us.Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit a2f18db0c68fec96631c10cad9384c196e9008ac upstream.
Jumping between chains doesn't mix well with flush ruleset. Rules
from a different chain and set elements may still refer to us.[ 353.373791] ------------[ cut here ]------------
[ 353.373845] kernel BUG at net/netfilter/nf_tables_api.c:1159!
[ 353.373896] invalid opcode: 0000 [#1] SMP
[ 353.373942] Modules linked in: intel_powerclamp uas iwldvm iwlwifi
[ 353.374017] CPU: 0 PID: 6445 Comm: 31c3.nft Not tainted 3.18.0 #98
[ 353.374069] Hardware name: LENOVO 5129CTO/5129CTO, BIOS 6QET47WW (1.17 ) 07/14/2010
[...]
[ 353.375018] Call Trace:
[ 353.375046] [] ? nf_tables_commit+0x381/0x540
[ 353.375101] [] nfnetlink_rcv+0x3d8/0x4b0
[ 353.375150] [] netlink_unicast+0x105/0x1a0
[ 353.375200] [] netlink_sendmsg+0x32e/0x790
[ 353.375253] [] sock_sendmsg+0x8e/0xc0
[ 353.375300] [] ? move_addr_to_kernel.part.20+0x19/0x70
[ 353.375357] [] ? move_addr_to_kernel+0x19/0x30
[ 353.375410] [] ? verify_iovec+0x42/0xd0
[ 353.375459] [] ___sys_sendmsg+0x3f0/0x400
[ 353.375510] [] ? native_sched_clock+0x2a/0x90
[ 353.375563] [] ? acct_account_cputime+0x17/0x20
[ 353.375616] [] ? account_user_time+0x88/0xa0
[ 353.375667] [] __sys_sendmsg+0x3d/0x80
[ 353.375719] [] ? int_check_syscall_exit_work+0x34/0x3d
[ 353.375776] [] SyS_sendmsg+0xd/0x20
[ 353.375823] [] system_call_fastpath+0x16/0x1bRelease objects in this order: rules -> sets -> chains -> tables, to
make sure no references to chains are held anymore.Reported-by: Asbjoern Sloth Toennesen
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit 9ea2aa8b7dba9e99544c4187cc298face254569f upstream.
Make sure there is enough room for the nfnetlink header in the
netlink messages that are part of the batch. There is a similar
check in netlink_rcv_skb().Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit 45f87de57f8fad59302fd263dd81ffa4843b5b24 upstream.
Commit 2457aec63745 ("mm: non-atomically mark page accessed during page
cache allocation where possible") has added a separate parameter for
specifying gfp mask for radix tree allocations.Not only this is less than optimal from the API point of view because it
is error prone, it is also buggy currently because
grab_cache_page_write_begin is using GFP_KERNEL for radix tree and if
fgp_flags doesn't contain FGP_NOFS (mostly controlled by fs by
AOP_FLAG_NOFS flag) but the mapping_gfp_mask has __GFP_FS cleared then
the radix tree allocation wouldn't obey the restriction and might
recurse into filesystem and cause deadlocks. This is the case for most
filesystems unfortunately because only ext4 and gfs2 are using
AOP_FLAG_NOFS.Let's simply remove radix_gfp_mask parameter because the allocation
context is same for both page cache and for the radix tree. Just make
sure that the radix tree gets only the sane subset of the mask (e.g. do
not pass __GFP_WRITE).Long term it is more preferable to convert remaining users of
AOP_FLAG_NOFS to use mapping_gfp_mask instead and simplify this
interface even further.Reported-by: Dave Chinner
Signed-off-by: Michal Hocko
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
