* Fix sparse NULL pointer warning
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUuHr2AAoJENfPZGlqN0++WpMQAKUFwJeEjYV5dErLTbmiLOuu
iCCF7my9tTCU2JQZgjRlmGXCvMA7vI+Zhn8b902bNHvICIuVkFFdgtoF3uZ+dd1i
vix9nGsN3UaodsTYl0xfXT6n/YW1DndjIqL2Za7sj1UFhAIpWJWef1UfTQjV8UcR
jllcVsrLsoJedZUgbDZmGvR9D0nxtIJPintPSn/xrWIbG/sMHrP2lo4rcme2seHg
BwGXVgRl+jGXtH7ZJ8JJ0+PbrECP/QaF0Df3gr8WaU7n/K4y1xkJboJLChQvPGMk
9h/a97f5QwZr2ZzOsDirtjgKi7Z9SiOakxmVfaK2kftv27qgp45/JXBSLTi3chQ4
xLvAA/o9lDhlAH7u7QiUuJ+w0JCC2fg8Jeg+npgfW2oLqJlokgMUaVgHbwqg9++T
qKCBdi+B0dZ5m+AdDyWX6qTWnP8IXYKm++JImylwqyXM2SuF4K/Ef7goF5bON5W3
EvvKB3tX2VDj4+RvotIRY9BisD0W9dsvil7ylK5pCIBTGIGThwO4RJSLTrWyjBLc
j9T4a7EHwpfX9S5P/B/SlufTMdC9Yn7+KSI05qXue5QIqMPGG4OrOdUOj93Oh+Eg
jGlffRU5rGAOwHLFzFMU9s88rdv98LoVfDnVCS0qRFYRySSoBHxHTx+VtKXdTy8E
kV7fodPjoYZidLIR4Co4
=J+Mz
-----END PGP SIGNATURE-----
Merge tag 'renesas-sh73a0-ccf2-for-v3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/drivers
Merge "Second Round of Renesas ARM Based SoC Sh73a0 CCF Updates for v3.20" from
Simon Horman:
Second Round of Renesas ARM Based SoC Sh73a0 CCF Updates for v3.20
* Fix sparse NULL pointer warning
* tag 'renesas-sh73a0-ccf2-for-v3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
clk: shmobile: fix sparse NULL pointer warning
Signed-off-by: Olof Johansson <olof@lixom.net>
* Enable kzm9g board in multiplatform defconfig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUuGlZAAoJENfPZGlqN0++lJMP/15YVPqRgXoIC0UIF/mit3II
SPbegYxShx0cuwc8AeYCXYuyjWRGEdWi/+bh6Lv9qy7o2g0ijs8J6739xxA2QlwT
wVyEEYdV4TI12UumO5UXw2NDmCQskK54OjqtLPXaeU/l08yu+id+/WV0nVU2ib1/
45qhuerjhzry/UHgeNz98h+XULTWLDlWw7IfQg+65OHXo9we0x6HVGztIncahK7v
qUIVubD4gj/WFw+oSVJQmMf53TtwL8XJxYhP6KzBHC5S1MARMk/suW9AhWCExlNM
bJHwNEiIU64cK5uDUQmlTRY0PIAU5wm/FUK/VdpW2q9vedhi2KTOyjnmKjk+4VRN
a8fPs64CbIv7g7r6c+Gur0nVJbpj/wSeUZowLfapGquhJSwv69n7LtI0EG+XXB6Y
arL0+BhutS1vcEC1wxelFUDy73GnYPnaFVCpfeF/LHvnvjyzCobaFa9j4rYTYuE/
LgTypu+3UElQqQ4r06hroh+HqFto8n8XbQmNm926I1U7vkJugII1L7t4HRGHT1Ih
PtSES38JG8fLyieaQ+D9oHUMAJWJp7RoIGXGw+Ujp6lcH/xEeUk2g2pl7CFKHQ0L
WFNOvjwcsJdHCef9tUq8e7URCoHAPl1cYFRc1OWvAjYPfSqQlp77gH10MZKm/AK7
QUwKYVCOJsXlSheGWLaX
=QtoG
-----END PGP SIGNATURE-----
Merge tag 'renesas-defconfig2-for-v3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/defconfig
Merge "Second Round of Renesas ARM Based SoC Defconfig Updates for v3.20" from
Simon Horman:
Second Round of Renesas ARM Based SoC Defconfig Updates for v3.20
* Enable kzm9g board in multiplatform defconfig
* tag 'renesas-defconfig2-for-v3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: Enable kzm9g board in multiplatform defconfig
Signed-off-by: Olof Johansson <olof@lixom.net>
Add dts file for Hisilicon hip01 ca9x2 board
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
[olof: Folded in smp enable-method from a different patch]
Signed-off-by: Olof Johansson <olof@lixom.net>
Enable smp for HiP01 board.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
[olof: split off the dts change to a separate commit]
Signed-off-by: Olof Johansson <olof@lixom.net>
As hix5hd2 and hip01 has the same secondary_startup
so rename hix5hd2_secondary_startup to
to hisi_secondary_startup.
the hip01 will use hisi_secondary_startup for the
secondary core boot.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
As hix5hd2 and hip01 has the same .smp_prepare_cpus
in struct smp_operations, so rename hix5hd2_smp_prepare_cpus
to hisi_common_smp_prepare_cpus.
the hip01 will use hisi_common_smp_prepare_cpus in its
struct smp_operations.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Make hip01 share the hisi_defconfig.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Enable Hisilicon HiP01 SoC. This HiP01 SoC series support both
one core or dual cores and quad cores. The core is Cortex A9.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Add the support of Hisilicon HiP01 debug uart.
The uart of hip01 is 8250 compatible.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
When the superblock is modified in a transaction, the commonly
modified fields are not actually copied to the superblock buffer to
avoid the buffer lock becoming a serialisation point. However, there
are some other operations that modify the superblock fields within
the transaction that don't directly log to the superblock but rely
on the changes to be applied during the transaction commit (to
minimise the buffer lock hold time).
When we do this, we fail to mark the buffer log item as being a
superblock buffer and that can lead to the buffer not being marked
with the corect type in the log and hence causing recovery issues.
Fix it by setting the type correctly, similar to xfs_mod_sb()...
cc: <stable@vger.kernel.org> # 3.10 to current
Tested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Conversion from local to extent format does not set the buffer type
correctly on the new extent buffer when a symlink data is moved out
of line.
Fix the symlink code and leave a comment in the generic bmap code
reminding us that the format-specific data copy needs to set the
destination buffer type appropriately.
cc: <stable@vger.kernel.org> # 3.10 to current
Tested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This leads to log recovery throwing errors like:
XFS (md0): Mounting V5 Filesystem
XFS (md0): Starting recovery (logdev: internal)
XFS (md0): Unknown buffer type 0!
XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
ffff8800ffc53800: 58 41 47 49 .....
Which is the AGI buffer magic number.
Ensure that we set the type appropriately in both unlink list
addition and removal.
cc: <stable@vger.kernel.org> # 3.10 to current
Tested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is the init support for CSR Atlas7 new SoC. Old Marco has never
shipped to customers and been dropped.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJUvkR1AAoJEDIv4aC191RhkggQAIoZYo46hGunj4Biqb9EFJp4
R0wS/iDVDyul+0WOXNkbuaOscQMwWvez2PXB/1C+1fiKAhhC1OIFs2hb5flAqDFe
vkhT5ZpO/htVDNOCEEeRLMmI3OjNBlwDhRziiiC86k99UQn8xDSruSGgYNE2AeU2
az3OMTuHiXiizey2c+B5qQNJy/rMQo4bN6MRRbUBUlr7B8J0fF/dA1jRyDI5llki
spvac3EoVGyTeQlAFCEc7jzx1oiGHsBmNA5xMMsuun6AANkyNvE+S+/1952T9Tg2
Vk07l4mFLRS45dsRfHrA6zwUrGtNs5WxfUF18mjwFl8i/Bh1FuLUsDoE4KiEVzKR
4qClHqq3i4TFBwoUCFUBswIpNluAx0Qr7yN0cKxSSaZDre4aUCSx4bRqGZrP14rN
YD+JknEOOmo9nk3n7QTUPJ7aZZk/o/nbH2OPNj1pXxMYn8wMCoJghOYTwqax6pgY
j6zpraNjaAPfnG12O0YU/6NBF1+G3P5jG/mmOTp1y5JbNGVWIm8kzdu5ulLJ/EJt
XpVMP1PKijjHyZ/JZZf18cBGXaDM0xjZI8ugSDLBQ8t8o+1d0pE82AAJjGtOF+3f
OCaNEjUSiMK6QWPhkUjQUL2kdI0VAEAn+AbRkNbqYXYRiL4Q85h0Tmbr0wtKypq+
axqq+/wEuZ18IvDMP6dh
=vStR
-----END PGP SIGNATURE-----
Merge tag 'new-atlas7mach-for-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux into next/soc
Merge "CSR new atlas7 machine, and delete old marco machine for 3.20" from
Barry Song:
drop CSR Marco machine and add Atlas7 new machine
This is the init support for CSR Atlas7 new SoC. Old Marco has never
shipped to customers and been dropped.
* tag 'new-atlas7mach-for-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux:
ARM: sirf: add Atlas7 machine support
ARM: sirf: move to debug_ll_io_init and drop map_io
ARM: sirf: move platsmp to support Atlas7 SoC
ARM: sirf: drop Marco machine
ARM: sirf: drop Marco support in reset controller module
Signed-off-by: Olof Johansson <olof@lixom.net>
Jan Kara reported that log recovery was finding buffers with invalid
types in them. This should not happen, and indicates a bug in the
logging of buffers. To catch this, add asserts to the buffer
formatting code to ensure that the buffer type is in range when the
transaction is committed.
We don't set a type on buffers being marked stale - they are not
going to get replayed, the format item exists only for recovery to
be able to prevent replay of the buffer, so the type does not
matter. Hence that needs special casing here.
cc: <stable@vger.kernel.org> # 3.10 to current
Reported-by: Jan Kara <jack@suse.cz>
Tested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Because Marco chip has never shipped to customers and has been replaced
by Atlas7, so we do the below
- drop Marco's debug port
- add debug ports for Atlas7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJUvkFoAAoJEDIv4aC191RhDlUP/3MbRNT5jDLm82r1ZXaetXi/
s2BeGuv313gceDAwWuNTISL855/dnEi56ifQtQUSRVWEadt199XLsugRPJ1xForF
zo/VZ/0WkzyRx3mPrGQtjUkt0Tj4S6W6IwhYfjKjh4lNF1KsiTGM2UQnKgnqZD/w
zqTGbK1WbcecQu02FcyhPX65Ic2kA18Mp0iMBANP4mLRQo5nfQ0fCGyHZ0DCAwHm
RsYoDKekemheo7+hVQi9KAGioF3M+D6w4L0tsTciHMPDdwy68xuK1JcRL1x3545k
m7yaj73bB7f4YmuvFgTcaA3BeiG1ZyyWA5yCwbzcTuhBMFenWJJnzvv7ykhPzvax
z3R8E331+ZJLXHjUQdq6rDrZtuoEH4j1fZExgUmg2C3OGYSnhQLPMCwEniXTuMsE
RbOarwGZZEm6fdSKqsHmhjKR5hMEQcScoQv7SnIrMvq+XPAJRI3VM9iLKiRChn0r
af8PwkL1lLVSDI9Kbsg+S/QlH1SuSSew9CnBvyrII7DDY8om8mgVDw46QWwYuytc
ELHCok9sNUbBjE/y7QwLIIIx4O1oAQ4BrYDKHFUpvVKlWjo8qmJ7+x4d9D02qp/y
yfUjdZD04++45CrptDw1o6D0lhxN6aedJ6A7mIVYI2v3vO3fpSWFVKkxl6B4vNQC
7myeOF+fryWiQADYcmOk
=Zt2B
-----END PGP SIGNATURE-----
Merge tag 'atlas7-lldebug-for-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux into next/soc
Merge "CSR atlas7 debug ports for 3.20" from Barry Song:
add debug ports for CSRatlas7 SoC
Because Marco chip has never shipped to customers and has been replaced
by Atlas7, so we do the below
- drop Marco's debug port
- add debug ports for Atlas7
* tag 'atlas7-lldebug-for-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux:
ARM: sirf: add two debug ports for CSRatlas7 SoC
ARM: sirf: drop Marco low-level debug port
Signed-off-by: Olof Johansson <olof@lixom.net>
This function call was being optimized out during nfs_fhget(), leading
to situations where we have a valid fileid but still want to use the
mounted_on_fileid. For example, imagine we have our server configured
like this:
server % df
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 9.1G 6.5G 1.9G 78% /
/dev/vdb1 487M 2.3M 456M 1% /exports
/dev/vdc1 487M 2.3M 456M 1% /exports/vol1
/dev/vdd1 487M 2.3M 456M 1% /exports/vol2
If our client mounts /exports and tries to do a "chown -R" across the
entire mountpoint, we will get a nasty message warning us about a circular
directory structure. Running chown with strace tells me that each directory
has the same device and inode number:
newfstatat(AT_FDCWD, "/nfs/", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
newfstatat(4, "vol1", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
newfstatat(4, "vol2", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
With this patch the mounted_on_fileid values are used for st_ino, so the
directory loop warning isn't reported.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
We currently have to ensure that every time we update sb_features2
that we update sb_bad_features2. Now that we log and format the
superblock in it's entirety we actually don't have to care because
we can simply update the sb_bad_features2 when we format it into the
buffer. This removes the need for anything but the mount and
superblock formatting code to care about sb_bad_features2, and
hence removes the possibility that we forget to update bad_features2
when necessary in the future.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
We now have several superblock loggin functions that are identical
except for the transaction reservation and whether it shoul dbe a
synchronous transaction or not. Consolidate these all into a single
function, a single reserveration and a sync flag and call it
xfs_sync_sb().
Also, xfs_mod_sb() is not really a modification function - it's the
operation of logging the superblock buffer. hence change the name of
it to reflect this.
Note that we have to change the mp->m_update_flags that are passed
around at mount time to a boolean simply to indicate a superblock
update is needed.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When we log changes to the superblock, we first have to write them
to the on-disk buffer, and then log that. Right now we have a
complex bitfield based arrangement to only write the modified field
to the buffer before we log it.
This used to be necessary as a performance optimisation because we
logged the superblock buffer in every extent or inode allocation or
freeing, and so performance was extremely important. We haven't done
this for years, however, ever since the lazy superblock counters
pulled the superblock logging out of the transaction commit
fast path.
Hence we have a bunch of complexity that is not necessary that makes
writing the in-core superblock to disk much more complex than it
needs to be. We only need to log the superblock now during
management operations (e.g. during mount, unmount or quota control
operations) so it is not a performance critical path anymore.
As such, remove the complex field based logging mechanism and
replace it with a simple conversion function similar to what we use
for all other on-disk structures.
This means we always log the entirity of the superblock, but again
because we rarely modify the superblock this is not an issue for log
bandwidth or CPU time. Indeed, if we do log the superblock
frequently, delayed logging will minimise the impact of this
overhead.
[Fixed gquota/pquota inode sharing regression noticed by bfoster.]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
We only support swap file calling nfs_direct_IO. However, application
might be able to get to nfs_direct_IO if it toggles O_DIRECT flag
during IO and it can deadlock because we grab inode->i_mutex in
nfs_file_direct_write(). So return 0 for such case. Then the generic
layer will fall back to buffer IO.
Signed-off-by: Peng Tao <tao.peng@primarydata.com>
Cc: stable@vger.kernel.org
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Put controller into init mode in network stop to end pending transmissions. The
issue is observed in cases when transmitted frame is not acked.
Signed-off-by: Viktor Babrian <babrian.viktor@renyi.mta.hu>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Use <driver>-$(CONFIG_FOO) syntax to build multipart objects with
optional parts, since all the config options are bool. Also, delete the
obvious comments in the usbhid Makefile.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Rockchip support is not limited to Cortex-A9 socs anymore and its
presence may confuse people reading /proc/cpuinfo. So remove the core
specific part.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
We hit use after free on dereferncing pointer to task_smack struct in
smk_of_task() called from smack_task_to_inode().
task_security() macro uses task_cred_xxx() to get pointer to the task_smack.
task_cred_xxx() could be used only for non-pointer members of task's
credentials. It cannot be used for pointer members since what they point
to may disapper after dropping RCU read lock.
Mainly task_security() used this way:
smk_of_task(task_security(p))
Intead of this introduce function smk_of_task_struct() which
takes task_struct as argument and returns pointer to smk_known struct
and do this under RCU read lock.
Bogus task_security() macro is not used anymore, so remove it.
KASan's report for this:
AddressSanitizer: use after free in smack_task_to_inode+0x50/0x70 at addr c4635600
=============================================================================
BUG kmalloc-64 (Tainted: PO): kasan error
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: Allocated in new_task_smack+0x44/0xd8 age=39 cpu=0 pid=1866
kmem_cache_alloc_trace+0x88/0x1bc
new_task_smack+0x44/0xd8
smack_cred_prepare+0x48/0x21c
security_prepare_creds+0x44/0x4c
prepare_creds+0xdc/0x110
smack_setprocattr+0x104/0x150
security_setprocattr+0x4c/0x54
proc_pid_attr_write+0x12c/0x194
vfs_write+0x1b0/0x370
SyS_write+0x5c/0x94
ret_fast_syscall+0x0/0x48
INFO: Freed in smack_cred_free+0xc4/0xd0 age=27 cpu=0 pid=1564
kfree+0x270/0x290
smack_cred_free+0xc4/0xd0
security_cred_free+0x34/0x3c
put_cred_rcu+0x58/0xcc
rcu_process_callbacks+0x738/0x998
__do_softirq+0x264/0x4cc
do_softirq+0x94/0xf4
irq_exit+0xbc/0x120
handle_IRQ+0x104/0x134
gic_handle_irq+0x70/0xac
__irq_svc+0x44/0x78
_raw_spin_unlock+0x18/0x48
sync_inodes_sb+0x17c/0x1d8
sync_filesystem+0xac/0xfc
vdfs_file_fsync+0x90/0xc0
vfs_fsync_range+0x74/0x7c
INFO: Slab 0xd3b23f50 objects=32 used=31 fp=0xc4635600 flags=0x4080
INFO: Object 0xc4635600 @offset=5632 fp=0x (null)
Bytes b4 c46355f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object c4635600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object c4635610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object c4635620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object c4635630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Redzone c4635640: bb bb bb bb ....
Padding c46356e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Padding c46356f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
CPU: 5 PID: 834 Comm: launchpad_prelo Tainted: PBO 3.10.30 #1
Backtrace:
[<c00233a4>] (dump_backtrace+0x0/0x158) from [<c0023dec>] (show_stack+0x20/0x24)
r7:c4634010 r6:d3b23f50 r5:c4635600 r4:d1002140
[<c0023dcc>] (show_stack+0x0/0x24) from [<c06d6d7c>] (dump_stack+0x20/0x28)
[<c06d6d5c>] (dump_stack+0x0/0x28) from [<c01c1d50>] (print_trailer+0x124/0x144)
[<c01c1c2c>] (print_trailer+0x0/0x144) from [<c01c1e88>] (object_err+0x3c/0x44)
r7:c4635600 r6:d1002140 r5:d3b23f50 r4:c4635600
[<c01c1e4c>] (object_err+0x0/0x44) from [<c01cac18>] (kasan_report_error+0x2b8/0x538)
r6:d1002140 r5:d3b23f50 r4:c6429cf8 r3:c09e1aa7
[<c01ca960>] (kasan_report_error+0x0/0x538) from [<c01c9430>] (__asan_load4+0xd4/0xf8)
[<c01c935c>] (__asan_load4+0x0/0xf8) from [<c031e168>] (smack_task_to_inode+0x50/0x70)
r5:c4635600 r4:ca9da000
[<c031e118>] (smack_task_to_inode+0x0/0x70) from [<c031af64>] (security_task_to_inode+0x3c/0x44)
r5:cca25e80 r4:c0ba9780
[<c031af28>] (security_task_to_inode+0x0/0x44) from [<c023d614>] (pid_revalidate+0x124/0x178)
r6:00000000 r5:cca25e80 r4:cbabe3c0 r3:00008124
[<c023d4f0>] (pid_revalidate+0x0/0x178) from [<c01db98c>] (lookup_fast+0x35c/0x43y4)
r9:c6429efc r8:00000101 r7:c079d940 r6:c6429e90 r5:c6429ed8 r4:c83c4148
[<c01db630>] (lookup_fast+0x0/0x434) from [<c01deec8>] (do_last.isra.24+0x1c0/0x1108)
[<c01ded08>] (do_last.isra.24+0x0/0x1108) from [<c01dff04>] (path_openat.isra.25+0xf4/0x648)
[<c01dfe10>] (path_openat.isra.25+0x0/0x648) from [<c01e1458>] (do_filp_open+0x3c/0x88)
[<c01e141c>] (do_filp_open+0x0/0x88) from [<c01ccb28>] (do_sys_open+0xf0/0x198)
r7:00000001 r6:c0ea2180 r5:0000000b r4:00000000
[<c01cca38>] (do_sys_open+0x0/0x198) from [<c01ccc00>] (SyS_open+0x30/0x34)
[<c01ccbd0>] (SyS_open+0x0/0x34) from [<c001db80>] (ret_fast_syscall+0x0/0x48)
Read of size 4 by thread T834:
Memory state around the buggy address:
c4635380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
c4635400: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
c4635480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
c4635500: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
c4635580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>c4635600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
c4635680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
c4635700: 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc fc
c4635780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
c4635800: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
c4635880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Cc: <stable@vger.kernel.org>
To guerantee proper charing and managing batteries even in suspend,
charger-manager has used rtc device with rtc framework interface.
However, it is better to use alarmtimer for cleaner and more appropriate
operation.
This patch makes driver to use alarmtimer for polling work in suspend and
removes all deprecated codes related with using rtc interface.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
at91_poweroff_get_wakeup_mode can return a negative error code and should
therefore not return an enum type. Similar, its result should not be
assigned to an enum type. Otherwise, the returned value is never negative,
resulting in a compiler warning and a missed error condition, which in turn
results in writing bad values into a chip register.
Also fix other compiler warnings which can be easily avoided.
drivers/power/reset/at91-poweroff.c:74:24:
warning: type qualifiers ignored on function return type
drivers/power/reset/at91-poweroff.c:74:24:
warning: no previous prototype for 'at91_poweroff_get_wakeup_mode'
drivers/power/reset/at91-poweroff.c:83:16:
warning: comparison between signed and unsigned integer expressions
drivers/power/reset/at91-poweroff.c:97:2:
warning: comparison of unsigned expression < 0 is always false
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
In current driver, power_supply_changed() is called whenever any of
the battery attribute changed. This causes kernel to increases the
'/sys/power/wakeup_count' and make suspend not working correctly.
This patch change this behavior to call power_supply_changed()
only when the battery capacity changed.
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
- SOC is at 0x1C so we must add 0x4 as stated in the comment to read the
right value.
- DCAP is at 0x3c so we also must use a value with the right offset to get
the correct design capacity.
Actually testing on a bq27410 which has the same register map as bq27425
(but adds new registers).
Signed-off-by: Eric Bénard <eric@eukrea.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This is only a small clean-up. The driver can be built without SYSFS
as there exist stubs for used functions.
Signed-off-by: Karol Wrona <k.wrona@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
because gcc 4.8 for superH does not support -m32, and the recordmcount.pl
script adds "-m32" when re-compiling the object files with the mcount
locations.
I was not able to reproduce this problem, as it seems that -m32 works fine
for my cross compiler gcc 4.6.3, but I have to assume that -m32 was
deprecated somewhere between 4.6 and 4.8. As it still seems to compile
fine without -m32, I have no reason not to add this patch, as having
-m32 seems to cause trouble for others.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUv9sOAAoJEEjnJuOKh9ldPUIIAJle6R3v+53gylalVhOnn56f
fQkONz1HvLteneBGTFG4xiwK6BJNeTOcLOQbCfBwNBZUjg7QG5eEU3wBG6DCZNIf
Tc1DqB78Fx9HnI0wJby/VtgIMbTqvPsXta0J75g7EFXwaP8bUZFL1s6QmskKlFTf
Gvhr93YP2SFawRf8Gy9AVCkLBSwU1T5y0IsQXPw49buNT+aWwoMWCNJb03rLfZYz
MCNgTfQxf4aYK1EThvb8xurjD2rZkJmRc/LN37vj8M+2e9HoIitCd4O/doxEQtvK
aFw7q/K23bFIXfjKoF1Yjk8hLoQZgCxruZwmZyxEEPtTGsUfNcSyfgpHTNeNDrk=
=d6qd
-----END PGP SIGNATURE-----
Merge tag 'trace-sh-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull superh tracing fix from Steven Rostedt:
"It's been reported that function tracing does not work on the sh
architecture because gcc 4.8 for superH does not support -m32, and the
recordmcount.pl script adds "-m32" when re-compiling the object files
with the mcount locations.
I was not able to reproduce this problem, as it seems that -m32 works
fine for my cross compiler gcc 4.6.3, but I have to assume that -m32
was deprecated somewhere between 4.6 and 4.8. As it still seems to
compile fine without -m32, I have no reason not to add this patch, as
having -m32 seems to cause trouble for others"
* tag 'trace-sh-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore
xfs_fs_get_xstate() and xfs_fs_get_xstatev() check whether there's quota
running before calling xfs_qm_scall_getqstat() or
xfs_qm_scall_getqstatv(). Thus we are certain that superblock supports
quota and xfs_sb_version_hasquota() check is pointless. Similarly we
know that when quota is running, mp->m_quotainfo will be allocated.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
'flags' have XFS_ALL_QUOTA_ACCT cleared immediately on function entry.
There's no point in checking these bits later in the function. Also
because we check something is going to change, we know some enforcement
bits are being added and thus there's no point in testing that later.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Q_XQUOTARM is never passed to xfs_fs_set_xstate() so remove the test.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Currently flags passed via Q_SETINFO were just stored. This makes it
hard to add new flags since in theory userspace could be just setting /
clearing random flags. Since currently there is only one userspace
settable flag and that is somewhat obscure flags only for ancient v1
quota format, I'm reasonably sure noone operates these flags and
hopefully we are fine just adding the check that passed flags are sane.
If we indeed find some userspace program that gets broken by the strict
check, we can always remove it again.
Signed-off-by: Jan Kara <jack@suse.cz>
Currently all quota flags were defined just in kernel-private headers.
Export flags readable / writeable from userspace to userspace via
include/uapi/linux/quota.h.
Signed-off-by: Jan Kara <jack@suse.cz>
OLQF_CLEAN flag is used by OCFS2 on disk to recognize whether quota
recovery is needed or not. We also somewhat abuse mem_dqinfo->dqi_flags
to pass this flag around. Use private flags for this to avoid clashes
with other quota flags / not pollute generic quota flag namespace.
Signed-off-by: Jan Kara <jack@suse.cz>
Currently, v2 quota format blindly stored flags from in-memory dqinfo on
disk, although there are no flags supported. Since it is stupid to store
flags which have no effect, just store 0 unconditionally and don't
bother loading it from disk.
Note that userspace could have stored some flags there via Q_SETINFO
quotactl and then later read them (although flags have no effect) but
I'm pretty sure noone does that (most definitely quota-tools don't and
quota interface doesn't have too much other users).
Signed-off-by: Jan Kara <jack@suse.cz>
blkdev_issue_discard() will zero a given block range. This is done by
way of explicit writing, thus provisioning or allocating the blocks on
disk.
There are use cases where the desired behavior is to zero the blocks but
unprovision them if possible. The blocks must deterministically contain
zeroes when they are subsequently read back.
This patch adds a flag to blkdev_issue_zeroout() that provides this
variant. If the discard flag is set and a block device guarantees
discard_zeroes_data we will use REQ_DISCARD to clear the block range. If
the device does not support discard_zeroes_data or if the discard
request fails we will fall back to first REQ_WRITE_SAME and then a
regular REQ_WRITE.
Also update the callers of blkdev_issue_zero() to reflect the new flag
and make sb_issue_zeroout() prefer the discard approach.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
With removal of backing_dev_info from struct address_space,
we don't need to assign it in Lustre either.
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Jens Axboe <axboe@fb.com>
Hi,
If you can manage to submit an async write as the first async I/O from
the context of a process with realtime scheduling priority, then a
cfq_queue is allocated, but filed into the wrong async_cfqq bucket. It
ends up in the best effort array, but actually has realtime I/O
scheduling priority set in cfqq->ioprio.
The reason is that cfq_get_queue assumes the default scheduling class and
priority when there is no information present (i.e. when the async cfqq
is created):
static struct cfq_queue *
cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
struct bio *bio, gfp_t gfp_mask)
{
const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
cic->ioprio starts out as 0, which is "invalid". So, class of 0
(IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so:
async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
static struct cfq_queue **
cfq_async_queue_prio(struct cfq_data *cfqd, int ioprio_class, int ioprio)
{
switch (ioprio_class) {
case IOPRIO_CLASS_RT:
return &cfqd->async_cfqq[0][ioprio];
case IOPRIO_CLASS_NONE:
ioprio = IOPRIO_NORM;
/* fall through */
case IOPRIO_CLASS_BE:
return &cfqd->async_cfqq[1][ioprio];
case IOPRIO_CLASS_IDLE:
return &cfqd->async_idle_cfqq;
default:
BUG();
}
}
Here, instead of returning a class mapped from the process' scheduling
priority, we get back the bucket associated with IOPRIO_CLASS_BE.
Now, there is no queue allocated there yet, so we create it:
cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask);
That function ends up doing this:
cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync);
cfq_init_prio_data(cfqq, cic);
cfq_init_cfqq marks the priority as having changed. Then, cfq_init_prio
data does this:
ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
switch (ioprio_class) {
default:
printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
case IOPRIO_CLASS_NONE:
/*
* no prio set, inherit CPU scheduling settings
*/
cfqq->ioprio = task_nice_ioprio(tsk);
cfqq->ioprio_class = task_nice_ioclass(tsk);
break;
So we basically have two code paths that treat IOPRIO_CLASS_NONE
differently, which results in an RT async cfqq filed into a best effort
bucket.
Attached is a patch which fixes the problem. I'm not sure how to make
it cleaner. Suggestions would be welcome.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Tested-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Since d621e8bae5 (Create of_mm_gpiochip_remove), there is a
counterpart for of_mm_gpiochip_add.
This patch implements the remove function of the driver making use of
it.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Station info state is started in allocation, so should be
destroyed on free (it's just a timer); rate control must
be freed if anything afterwards fails to initialize.
LED exit should be later, no need for locking there, but
it needs to be done also when rate init failed.
Also clean up the code by moving a label so the locking
doesn't have to be done separately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The PCIe spec (r3.0, sec 7.8.9) says Hot-Plug Surprise indicates support
for surprise *removal*, but pciehp checked this to determine if it should
handle presence detect interrupts for device *addition*.
Allow surprise device addition even if the slot doesn't advertise support
for surprise removal.
Keith has a platform with slots for front-loading SFF devices. The slots
do not have attention buttons and do not support surprise removal, but they
do have presence detect. In that case, we still want to use presence
detect for device addition.
Keith's original patch handled surprise insertions only if Hot-Plug Capable
is set. I think that test is superfluous because pciehp only claims slots
that advertise Hot-Plug Capable (see get_port_device_capability()).
Link: http://lkml.kernel.org/r/1419275223-14602-1-git-send-email-keith.busch@intel.com
Based-on-patch-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rajat Jain <rajatxjain@gmail.com>
The prior change fixes default output ordering with each column but it
breaks -o/--order option. This patch prepends a new hpp fmt struct to
sort list but not to output field list so that it can affect ordering
without adding a new output column.
The new hpp fmt uses its own compare functions which treats dummy
entries (which have no baseline) little differently - the delta field
can be computed without baseline but others (ratio and wdiff) are not.
The new output will look like below:
$ perf diff -o 2 perf.data.{old,cur,new}
...
# Baseline/0 Delta/1 Delta/2 Shared Object Symbol
# .......... ....... ....... ................. ..........................................
22.98% +0.51% +0.52% libc-2.20.so [.] _int_malloc
5.70% +0.28% +0.30% libc-2.20.so [.] free
4.38% -0.21% +0.25% a.out [.] main
1.32% -0.15% +0.05% a.out [.] free@plt
+0.01% [kernel.kallsyms] [k] intel_pstate_timer_func
+0.01% [kernel.kallsyms] [k] _raw_spin_lock_irqsave
+0.01% [kernel.kallsyms] [k] timekeeping_update.constprop.8
+0.01% +0.01% [kernel.kallsyms] [k] apic_timer_interrupt
0.01% -0.00% [kernel.kallsyms] [k] native_read_msr_safe
0.01% -0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
1.31% +0.03% -0.06% a.out [.] malloc@plt
31.50% -0.74% -0.23% libc-2.20.so [.] _int_free
32.75% +0.28% -0.83% libc-2.20.so [.] malloc
0.01% [kernel.kallsyms] [k] scheduler_tick
+0.01% [kernel.kallsyms] [k] read_tsc
+0.01% [kernel.kallsyms] [k] perf_adjust_freq_unthr_context.part.82
In above example, the output was sorted by 'Delta/2' column first, and
then 'Baseline/0' and finally 'Delta/1'.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1420677949-6719-8-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
