One more oversight in the debugfs code was reported and fixed, plus a
documentation fix.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRARV/AAoJELSic+t+oim9zE0QAICfs9wBiHPFLfjDUeGbta2F
3f1JRJ995oI8kA9JDujV2291XBCr690MCr/dpp6l19L7n3grzsPM3Oux+VuI0YQz
XxQUI9OSIq4A/Q9sP8hrbd+KPrn69aLjHAK4R4Rz3FtGaUuLb6sWrYL7xDNi3Cyr
mAZ5r//Wj8Z6PtjJdgLPN92k5X/EkIbO9A8BVUXX2Y2uVB3OeqWuJkFKqCZz2ha7
TheMW95hScsdeNKCpoPZCUD1r0tQ07U08q+poo4lTWBOxSv9JVw0HsZMVB0UpOG1
9q6NnX25zYRFIZnbBf2yjqz1Vf4JrRAjskidAVSCqFyaYjndRbsEnEJCXsrO3188
4luBgQYu4XN/1B3IgqyEdA3XjfSJRkZBfw/lB3k/EB1FmaZYg9jfwvhrDQOVLXYN
0Kaw4ZEwKu/B425adB2I13F4WEQzdqw8Fxl9rpS+HRTAJmoy7LZ91NskxwC4TemG
QAt3brOccwWj/4PUrYu4IIbfyOtnuQmDQ9K5XQYXdq1j4WV91bxo5y+FekHKCNcB
fSceA7vAXHeP/VUlylG+LNk/NGuoCh7I2b9NLEHe8HO2ytpUfWICtJrhvKCPJNSL
NC60aZsa7nYKEq/g0u5xszlH2uNGvO2rWVGIVI59XmJbKMsCAjhw8kSmmPicbKor
iALHcn/cd8DiZC8+SXMw
=O6T4
-----END PGP SIGNATURE-----
Merge tag 'regmap-fix-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"One more oversight in the debugfs code was reported and fixed, plus a
documentation fix."
* tag 'regmap-fix-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: fix small typo in regmap_bulk_write comment
regmap: debugfs: Fix seeking from the cache
Pull slave-dmaengine fixes from Vinod Koul:
"A few fixes on slave dmanengine. There are trivial fixes in imx-dma,
tegra-dma & ioat driver"
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
dma: tegra: implement flags parameters for cyclic transfer
dmaengine: imx-dma: Disable use of hw_chain to fix sg_dma transfers.
ioat: Fix DMA memory sync direction correct flag
btrfs_start_delalloc_inodes() locks the delalloc_inodes list, fetches the
first inode, unlocks the list, triggers btrfs_alloc_delalloc_work/
btrfs_queue_worker for this inode, and then it locks the list, checks the
head of the list again. But because we don't delete the first inode that it
deals with before, it will fetch the same inode. As a result, this function
allocates a huge amount of btrfs_delalloc_work structures, and OOM happens.
Fix this problem by splice this delalloc list.
Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
The max device number of single profile is 1, not 0 (0 means 'as many as
possible'). Fix it.
Cc: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
First, though the current transaction->aborted check can stop the commit early
and avoid unnecessary operations, it is too early, and some transaction handles
don't end, those handles may set transaction->aborted after the check.
Second, when we commit the transaction, we will wake up some worker threads to
flush the space cache and inode cache. Those threads also allocate some transaction
handles and may set transaction->aborted if some serious error happens.
So we need more check for ->aborted when committing the transaction. Fix it.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
We may access and update transaction->aborted on the different CPUs without
lock, so we need ACCESS_ONCE() wrapper to prevent the compiler from creating
unsolicited accesses and make sure we can get the right value.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
I noticed a WARN_ON going off when adding csums because we were going over
the amount of csum bytes that should have been allowed for an ordered
extent. This is a leftover from when we used to hold the csums privately
for direct io, but now we use the normal ordered sum stuff so we need to
make sure and check if we've moved on to another extent so that the csums
are added to the right extent. Without this we could end up with csums for
bytenrs that don't have extents to cover them yet. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
For compressed extents, the range of checksum is covered by disk length,
and the disk length is different with ram length, so we need to use disk
length instead to get us the right checksum.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
A user reported a BUG_ON(ret) that occured during tree log replay. Ret was
-EAGAIN, so what I think happened is that we removed an extent that covered
a bitmap entry and an extent entry. We remove the part from the bitmap and
return -EAGAIN and then search for the next piece we want to remove, which
happens to be an entire extent entry, so we just free the sucker and return.
The problem is ret is still set to -EAGAIN so we trip the BUG_ON(). The
user used btrfs-zero-log so I'm not 100% sure this is what happened so I've
added a WARN_ON() to catch the other possibility. Thanks,
Reported-by: Jan Steffens <jan.steffens@gmail.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
We drop the extent map tree lock while we're logging extents, so somebody
could come in and merge another extent into this one and screw up our
logging, or they could even remove us from the list which would keep us from
logging the extent or freeing our ref on it, so we need to make sure to not
clear LOGGING until after the extent is logged, and then we can merge it to
adjacent extents. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
At the moment the MSR driver only relies upon file system
checks. This means that anything as root with any capability set
can write to MSRs. Historically that wasn't very interesting but
on modern processors the MSRs are such that writing to them
provides several ways to execute arbitary code in kernel space.
Sample code and documentation on doing this is circulating and
MSR attacks are used on Windows 64bit rootkits already.
In the Linux case you still need to be able to open the device
file so the impact is fairly limited and reduces the security of
some capability and security model based systems down towards
that of a generic "root owns the box" setup.
Therefore they should require CAP_SYS_RAWIO to prevent an
elevation of capabilities. The impact of this is fairly minimal
on most setups because they don't have heavy use of
capabilities. Those using SELinux, SMACK or AppArmor rules might
want to consider if their rulesets on the MSR driver could be
tighter.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Horses <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
I ran out of free entries when I had CONFIG_DMA_API_DEBUG
enabled. Some other archs seem to default to 65536, so increase
this limit for x86 too.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/50A612AA.7040206@canonical.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
----
From Pawel Moll:
- makes the V2P-CA15_A7 (a.k.a. TC2) work with 3.8 kernels
- improves vexpress-sysreg.c behaviour on arm64 platforms
* 'vexpress/fixes' of git://git.linaro.org/people/pawelmoll/linux:
mfd: vexpress-sysreg: Don't skip initialization on probe
ARM: vexpress: Enable A7 cores in V2P-CA15_A7's Device Tree
ARM: vexpress: extend the MPIDR range used for pen release check
One RM9200 setup option is the only C code change.
Some documentation changes can clarify the pinctrl use.
Then, some defconfig modifications are allowing the affected platforms
to boot.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJRAPnqAAoJEAf03oE53VmQbeUH/04lzIgUv63RX2zQFD6Fi1zD
IeYBhfzeSP65CPMqyFnw+lrHUdCWn0JYdFM6/x7J8n1k2+SY3T7N95k5oXlnqO6e
pT/XGontWQIZkyL0jkrawbs5QtE0OYnkm8Ge97qlhul4XoIiyWLFFGDHE36dzcv/
K4FPrG9PVVhjFIiZB+v5I3CnhzLWJvozn9J2ceIZ5d0Z9dwLuHWgXGu6OM2ZRvOw
LR1r2YpnGTKUT0am6tmWm1W7PY6ZQOQXmx5qX/H2X6gRQdq690baYUTOYPK3ZckX
kdEa+pCOQHY1GgimFzUzAVfoCyYwllo1yAWaK2a4qR4kxcaeGd1BYqlKeCFIfRc=
=aKwA
-----END PGP SIGNATURE-----
Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixes
From Nicolas Ferre:
Here are fixes for AT91 that are mainly related to device tree.
One RM9200 setup option is the only C code change.
Some documentation changes can clarify the pinctrl use.
Then, some defconfig modifications are allowing the affected platforms
to boot.
* tag 'at91-fixes' of git://github.com/at91linux/linux-at91:
ARM: at91/dts: correct comment in at91sam9x5.dtsi for mii
ARM: at91/at91_dt_defconfig: add at91sam9n12 SoC to DT defconfig
ARM: at91/at91_dt_defconfig: remove memory specification to cmdline
ARM: at91/dts: add macb mii pinctrl config for kizbox
ARM: at91: rm9200: remake the BGA as default version
ARM: at91: fix gpios on i2c-gpio for RM9200 DT
ARM: at91/at91sam9x5 DTS: add SCK USART pins
ARM: at91/at91sam9x5 DTS: correct wrong PIO BANK values on u(s)arts
ARM: at91/at91-pinctrl documentation: fix typo and add some details
Fix build errors when CONFIG_INPUT=m. This is not pretty, but
all of the OLPC kconfig options are bool instead of tristate.
arch/x86/built-in.o: In function `send_lid_state':
olpc-xo1-sci.c:(.text+0x1d323): undefined reference to `input_event'
olpc-xo1-sci.c:(.text+0x1d338): undefined reference to `input_event'
...
In the long run, fixing this driver kconfig to be tristate
instead of bool would be a very good change.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Andres Salomon <dilinger@queued.net>
Cc: Chris Ball <cjb@laptop.org>
Cc: Jon Nettleton <jon.nettleton@gmail.com>
Cc: Daniel Drake <dsd@laptop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The flush tlb optimization code has logical issue on UV
platform. It doesn't flush the full range at all, since it
simply ignores its 'end' parameter (and hence also the "all"
indicator) in uv_flush_tlb_others() function.
Cliff's notes:
| I tested the patch on a UV. It has the effect of either
| clearing 1 or all TLBs in a cpu. I added some debugging to
| test for the cases when clearing all TLBs is overkill, and in
| practice it happens very seldom.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Tested-by: Cliff Wickman <cpw@sgi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The vexpress-sysreg driver does not have to be initialized
early, when the platform doesn't require this. Unfortunately
in such case it wasn't initialized correctly - master site
lookup and config bridge registration were missing. Fixed now.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
As the kernel is able to cope with multiple clusters,
uncomment the A7 cores in the Device Tree for V2P-CA15_A7
tile, making all 5 cores available to the user.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
In ARM multi-cluster systems the MPIDR affinity level 0 cannot be used as a
single cpu identifier, affinity levels 1 and 2 must be taken into account as
well.
This patch extends the MPIDR usage to affinity levels 1 and 2 in versatile
secondary cores start up code in order to compare the passed pen_release
value with the full-blown affinity mask.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
While in one case a plain annotation is necessary, in the other
case the stack adjustment can simply be folded into the
immediately preceding RESTORE_ALL, thus getting the correct
annotation for free.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexander van Heukelum <heukelum@mailshack.com>
Link: http://lkml.kernel.org/r/51010C9302000078000B9045@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
maintainer for some time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJQ/qTBAAoJEFBXWFqHsHzOnNcH/0F8Ul4CJLS/+K80UaJDn7RQ
Di+4zPi/7foByJEUdTC9jDetHREPMeRLX2hzR+2XK+zCtrFPV8VAw4crdxOmLRYb
CxlTuMVA2R68NwvH1+PqTvuiJ6Qxr0HZHzmQdj+x8hWgRkD0RRoD/KQVbkrp8OKh
jJICgd3BXe9GTJszqK13Gj4VOfZvF9YyYDKAiKojfEOV3PyJTdnMBYGGQUD+6FHE
YxfG2xVUh/diFGpWxC5DLQdZ2ow+/7ruPTG+FifVGMcdqYI/KZ/l6cHiHNcFJcQs
6isObI8LeZ87kWJpM/cylqkzyyRGwg12jlFup22CBQCRyWgrgnGNVdoVBuffKJ0=
=Bup/
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-3.8-3' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
From Shawn Guo:
This is yet another critical imxfb fixes held off by absence of FB
maintainer for some time.
* tag 'imx-fixes-3.8-3' of git://git.linaro.org/people/shawnguo/linux-2.6:
video: imxfb: Do not crash on reboot
- fix memory leak in mvebu/clk-cpu.c
- use devm_ to correct/simplify error paths in mvsdio
- add missing #interrupt-cells property in kirkwood
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJQ/zvKAAoJEAi3KVZQDZAebCIIAKCaI3zYiHku7Q52Auzog0oU
7Gk6/TpZtolZURusjSVo8ZPWoZhJc9SoFAVkVJPcB9j1xTl3K7iNVOj4DVvi66o2
R8dw85nTKryBc6kapiJEpQhJof9dQKzmNSL36TNLaHjPef/hz3gVn/QqOxmyuBro
ZZI0aUm+idgaDFkQCuevcfuStQGaKdOsIr23QEbicTj0rbgy0OIKrQ2KxFGKnr0Z
YYYjUr9M5wk1mSOsssEcE/a97eejHS201JhYvCfxSpWCjbwiaErg0fzns7wZ2hhV
BKGAEs+M67gcaHR/Pi2fy3LNLtwIcVNNgFYF3aCiBEFQ+hqtar6O9zqSmlBk1bI=
=xOtK
-----END PGP SIGNATURE-----
Merge tag 'mvebu_fixes_for_v3.8-rc5' of git://git.infradead.org/users/jcooper/linux into fixes
From Jason Cooper:
mvebu fixes for v3.8-rc5
- fix memory leak in mvebu/clk-cpu.c
- use devm_ to correct/simplify error paths in mvsdio
- add missing #interrupt-cells property in kirkwood
* tag 'mvebu_fixes_for_v3.8-rc5' of git://git.infradead.org/users/jcooper/linux:
ARM: kirkwood: fix missing #interrupt-cells property
mmc: mvsdio: use devm_ API to simplify/correct error paths.
clk: mvebu/clk-cpu.c: fix memory leakage
Here are some more USB fixes for the 3.8-rc4 tree.
Some gadget driver fixes, and finally resolved the ehci-mxc driver build issues
(it's just some code moving around and being deleted).
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEABECAAYFAlEAeCEACgkQMUfUDdst+ynRygCeNs8Z0Nt+/quZHKf+/DS4vlRt
vBYAnAxbcPg1zWhMM+8AVt/YFYp83sfP
=5UpK
-----END PGP SIGNATURE-----
Merge tag 'usb-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull more USB fixes from Greg Kroah-Hartman:
"Here are some more USB fixes for the 3.8-rc4 tree.
Some gadget driver fixes, and finally resolved the ehci-mxc driver
build issues (it's just some code moving around and being deleted)."
* tag 'usb-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: EHCI: fix build error in ehci-mxc
USB: EHCI: add a name for the platform-private field
USB: EHCI: fix incorrect configuration test
USB: EHCI: Move definition of EHCI_STATS to ehci.h
USB: UHCI: fix IRQ race during initialization
usb: gadget: FunctionFS: Fix missing braces in parse_opts
usb: dwc3: gadget: fix ep->maxburst for ep0
ARM: i.MX clock: Change the connection-id for fsl-usb2-udc
usb: gadget: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap
usb: gadget: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
usb: musb: cppi_dma: drop '__init' annotation
Here is a single revert for the ti-st misc driver, fixing problem that was
introduced in 3.7-rc1 that has been bothering people.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEABECAAYFAlEAdxcACgkQMUfUDdst+ynQOgCgmsqcz6DaKFQpcMNKEl/6GWz2
KA4AoNYW3uSDQn1TUbuKmoJSN/SYALK4
=xqHP
-----END PGP SIGNATURE-----
Merge tag 'char-misc-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull drivers/misc fix from Greg Kroah-Hartman:
"Here is a single revert for the ti-st misc driver, fixing problem that
was introduced in 3.7-rc1 that has been bothering people."
* tag 'char-misc-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
Revert "drivers/misc/ti-st: remove gpio handling"
Just a MAINTAINERS update, now that Alan has left for a bit, I'll
continue to watch over the serial drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEABECAAYFAlEAdpEACgkQMUfUDdst+ym9cQCeLtZjj8FAz+VYcmHXFtJ9gK1C
9aEAn35RUUbVVZwN2QtIomah5Uz+2qPz
=KYh4
-----END PGP SIGNATURE-----
Merge tag 'tty-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull a TTY maintainer patch from Greg Kroah-Hartman:
"Just a MAINTAINERS update, now that Alan has left for a bit, I'll
continue to watch over the serial drivers."
* tag 'tty-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
MAINTAINERS: Someone needs to watch over the serial drivers
Pull media fixes from Mauro Carvalho Chehab:
- gspca: add needed delay for I2C traffic for sonixb/sonixj cameras
- gspca: add one missing Kinect USB ID
- usbvideo: some regression fixes
- omap3isp: fix some build issues
- videobuf2: fix video output handling
- exynos s5p/m5mols: a few regression fixes.
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] uvcvideo: Set error_idx properly for S_EXT_CTRLS failures
[media] uvcvideo: Cleanup leftovers of partial revert
[media] uvcvideo: Return -EACCES when trying to set a read-only control
[media] omap3isp: Don't include <plat/cpu.h>
[media] s5p-mfc: Fix interrupt error handling routine
[media] s5p-fimc: Fix return value of __fimc_md_create_flite_source_links()
[media] m5mols: Fix typo in get_fmt callback
[media] v4l: vb2: Set data_offset to 0 for single-plane output buffers
[media] [FOR,v3.8] omap3isp: Don't include deleted OMAP plat/ header files
[media] gspca_sonixj: Add a small delay after i2c_w1
[media] gspca_sonixb: Properly wait between i2c writes
[media] gspca_kinect: add Kinect for Windows USB id
Before attempting to activate a RAID array, it is checked for sufficient
redundancy. That is, we make sure that there are not too many failed
devices - or devices specified for rebuild - to undermine our ability to
activate the array. The current code performs this check twice - once to
ensure there were not too many devices specified for rebuild by the user
('validate_rebuild_devices') and again after possibly experiencing a failure
to read the superblock ('analyse_superblocks'). Neither of these checks are
sufficient. The first check is done properly but with insufficient
information about the possible failure state of the devices to make a good
determination if the array can be activated. The second check is simply
done wrong in the case of RAID10 because it doesn't account for the
independence of the stripes (i.e. mirror sets). The solution is to use the
properly written check ('validate_rebuild_devices'), but perform the check
after the superblocks have been read and we know which devices have failed.
This gives us one check instead of two and performs it in a location where
it can be done right.
Only RAID10 was affected and it was affected in the following ways:
- the code did not properly catch the condition where a user specified
a device for rebuild that already had a failed device in the same mirror
set. (This condition would, however, be caught at a deeper level in MD.)
- the code triggers a false positive and denies activation when devices in
independent mirror sets have failed - counting the failures as though they
were all in the same set.
The most likely place this error was introduced (or this patch should have
been included) is in commit 4ec1e369 - first introduced in v3.7-rc1.
Consequently this fix should also go in v3.7.y, however there is a
small conflict on the .version in raid_target, so I'll submit a
separate patch to -stable.
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Pull m68k fixes from Geert Uytterhoeven:
"The asm-generic changeset has been ack'ed by Arnd."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k: Wire up finit_module
asm-generic/dma-mapping-broken.h: Provide dma_alloc_attrs()/dma_free_attrs()
m68k: Provide dma_alloc_attrs()/dma_free_attrs()
If one (but not both) allocations of p->chunks[].kpage[]
in radeon_cs_parser_init fail, the error path will free
the successfully allocated page, but leave a stale pointer
value in the kpage[] field. This will later cause a
double-free when radeon_cs_parser_fini is called.
This patch fixes the issue by forcing both pointers to NULL
after kfree in the error path.
The circumstances under which the problem happens are very
rare. The card must be AGP and the system must run out of
kmalloc area just at the right time so that one allocation
succeeds, while the other fails.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This patch (as1643b) fixes a build error in ehci-hcd when compiling for
ARM with allmodconfig:
drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used [-Wunused-variable]
drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
The fix is to convert ehci-mxc over to the new "ehci-hcd is a library"
scheme so that it can coexist peacefully with the ehci-platform
driver. As part of the conversion the ehci_mxc_priv data structure,
which was allocated dynamically, is now placed where it belongs: in
the private area at the end of struct ehci_hcd.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This was introduced in commit 6dccd16 "r8169: merge with version
6.001.00 of Realtek's r8169 driver". I did not find the version
6.001.00 online, but in 6.002.00 or any later r8169 from Realtek
this hunk is no longer present.
Also commit 05af214 "r8169: fix Ethernet Hangup for RTL8110SC
rev d" claims to have fixed this issue otherwise.
The magic compare mask of 0xfffe000 is dubious as it masks
parts of the Reserved part, and parts of the VLAN tag. But this
does not make much sense as the VLAN tag parts are perfectly
valid there. In matter of fact this seems to be triggered with
any VLAN tagged packet as RxVlanTag bit is matched. I would
suspect 0xfffe0000 was intended to test reserved part only.
Finally, this hunk is evil as it can cause more packets to be
handled than what was NAPI quota causing net/core/dev.c:
net_rx_action(): WARN_ON_ONCE(work > weight) to trigger, and
mess up the NAPI state causing device to hang.
As result, any system using VLANs and having high receive
traffic (so that NAPI poll budget limits rtl_rx) would result
in device hang.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.
agd5f: check DCE6 rather than ARUBA since the issue is DCE
version specific rather than family specific.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
We create new flow caches when a new flow is identified by tuntap, This may lead
some issues:
- userspace may produce a huge amount of short live flows to exhaust host memory
- the unlimited number of flow caches may produce a long list which increase the
time in the linear searching
Solve this by introducing a limit of total number of flow caches.
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A MAX_TAP_QUEUES(1024) queues of tuntap device is always allocated
unconditionally even userspace only requires a single queue device. This is
unnecessary and will lead a very high order of page allocation when has a high
possibility to fail. Solving this by creating a one queue net device when
userspace only use one queue and also reduce MAX_TAP_QUEUES to
DEFAULT_MAX_NUM_RSS_QUEUES which can guarantee the success of
the allocation.
Reported-by: Dirk Hohndel <dirk@hohndel.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reverting 328d7b8 and instead adding an exception for the
Sierra Wireless MC7710.
commit 328d7b8 (net: cdc_mbim: send ZLP after max sized NTBs)
added a workaround for an issue observed on one specific device.
Concerns were raised that this workaround adds a performance
penalty to all devices based on questionable, if not buggy,
behaviour of a single device:
"If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU
load, increasing interrupt load by factor of 2 in high load traffic
scenario and possibly decreasing throughput for all other devices
which behaves correctly."
"The idea of NCM was to avoid extra ZLPs. If your transfer is exactly
dwNtbOutMaxSize, it's known, you can submit such request on the receiver
side and you do not need any EOT indicatation, so the frametime can be
used for useful data."
Adding a device specific exception to prevent the workaround from
affecting well behaved devices.
The assumption here is that needing a ZLP is truly an *exception*.
We do not yet have enough data to verify this. The generic
workaround in commit 328d7b8 should be considered acceptable despite
the performance penalty if the exception list becomes a maintainance
hassle.
Cc: Alexey ORISHKO <alexey.orishko@stericsson.com>
Cc: Yauheni Kaliuta <y.kaliuta@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Only a few small HD-audio fixes:
- Addition of new Conexant codec IDs
- Two one-liners to add fixups for Realtek codecs
- A last-minute regression fix for auto-mute with power-saving mode
(regressed since 3.8-rc1)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJQ//ylAAoJEGwxgFQ9KSmknOkP/AvgxVnTNUuZxbN/nD4DGK+K
DvssFEghDB4f0coYS0qozojKuSqJJBixG2swQz5qfq+6VaGG21uS/3dqh4S0iK9f
Q7mynqa0rB6o11oPNyvCcgj1gLULtvHYp8HbpO6OgJUxD0+De7875XSXfyGvysTY
n1H66UtjMZteqbj3VOes9dwme9qW3Z6KrppPvGcWQEL+M1dJE+cvW/IbH38/3P9l
3ihindwNQ3gGP5q5FQFF6R/ClkpLPJuGiTL9ZxNg5Oda1cvM7Of9vVck7LZiOpJv
K9snDFQmO9LQcp7lhey7c9K9iU8lr4yuan/x8lVA1RysKmdg9vwxKrUlVTs3ldFK
VkN8MDCMPacwDB3bli4paaAwItonFvIQ0l6vpsrb4rc1EBqg6L0wIEIJFuvo6jjf
zji7rgn8mGv/+Req/J8qDSZ/ZBQXrcvay4BiDeeY0FGp+Pxm5FjCq2lrqHRJZTWa
O6vwPDsSrFbWGTbU0f9H+fwMV/BcOYT8pw56ZqtZotRnUp8xMzAgRcWmAX+SBRXI
CMg92OiY8j++CGTI5mnigDFciRJJ3Y17duLqXlenZWl5dwvULcnspz6Mce4YrASk
2U+/5qH2hqc4IbI7Pr1bhQ6DjWoAbu0t7aCBbc0tsPe6UwuCjK9xYsRj+ing4zCq
/b1+nKukywP/hKnPq9kd
=1HAr
-----END PGP SIGNATURE-----
Merge tag 'sound-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Only a few small HD-audio fixes:
- Addition of new Conexant codec IDs
- Two one-liners to add fixups for Realtek codecs
- A last-minute regression fix for auto-mute with power-saving mode
(regressed since 3.8-rc1)"
* tag 'sound-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix inconsistent pin states after resume
ALSA: hda - Add Conexant CX20755/20756/20757 codec IDs
ALSA: hda - Add fixup for Acer AO725 laptop
ALSA: hda - Fix mute led for another HP machine
A Packard-Bell desktop machine gives no proper pin configuration from
BIOS. It's almost equivalent with the 6stack+fp standard config, just
take the existing fixup.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=901846
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Useful for statistics or on overflowing bug reports to keep things all
lined up.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The commit [26a6cb6c: ALSA: hda - Implement a poll loop for jacks as a
module parameter] introduced the polling jack detection code, but it
also moved the call of snd_hda_jack_set_dirty_all() in the resume path
after resume/init ops call. This caused a regression when the jack
state has been changed during power-down (e.g. in the power save
mode). Since the driver doesn't probe the new jack state but keeps
using the cached value due to no dirty flag, the pin state remains
also as if the jack is still plugged.
The fix is simply moving snd_hda_jack_set_dirty_all() to the original
position.
Reported-by: Manolo Díaz <diaz.manolo@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Concerning pinctrl_macb0_rmii_mii, values were okay, but not comments.
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
No need for this cmdline option as we are using DT.
Moreover this defconfig is targeted to multiple SoC/boards: this option
was nonsense.
Reported-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
This patch overrides default macb pinctrl config defined in
at91sam9260.dtsi (pinctrl_macb_rmii) with kizbox board config
(pinctrl_macb_rmii + pinctrl_macb_rmii_mii_alt).
Signed-off-by: Boris BREZILLON <linux-arm@overkiz.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Linus Torvalds