Searched hist:6035 (Results 1 - 20 of 20) sorted by relevance

/linux-master/arch/powerpc/kexec/
H A Drelocate_32.Sdiff 6035e7e3 Thu Dec 15 04:52:58 MST 2022 Sathvika Vasireddy <sv@linux.ibm.com> powerpc/32: Curb objtool unannotated intra-function call warning

objtool throws the following warning:
arch/powerpc/kexec/relocate_32.o: warning: objtool: .text+0x2bc: unannotated intra-function call

Fix this warning by annotating intra-function call, using
ANNOTATE_INTRA_FUNCTION_CALL macro, to indicate that the branch target
is valid.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20221215115258.80810-1-sv@linux.ibm.com
/linux-master/include/linux/mmc/
H A Dcore.hdiff 6035d973 Mon Jan 14 12:28:17 MST 2013 Konstantin Dorfman <kdorfman@codeaurora.org> mmc: fix async request mechanism for sequential read scenarios

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
H A Dcard.hdiff 6035d973 Mon Jan 14 12:28:17 MST 2013 Konstantin Dorfman <kdorfman@codeaurora.org> mmc: fix async request mechanism for sequential read scenarios

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
H A Dhost.hdiff 6035d973 Mon Jan 14 12:28:17 MST 2013 Konstantin Dorfman <kdorfman@codeaurora.org> mmc: fix async request mechanism for sequential read scenarios

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
/linux-master/arch/mips/kernel/
H A Dgenex.Sdiff 83e4da1e Mon Oct 07 17:39:31 MDT 2013 Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> MIPS: Print correct PC in trace dump after NMI exception

An NMI exception delivered from YAMON delivers the PC in ErrorPC
instead of EPC. It's also necessary to clear the Status.BEV
bit for the page fault exception handler to work properly.

[ralf@linux-mips: Let the assembler do the loading of the mask value rather
than the convoluted explicit %hi/%lo manual relocation sequence from the
original patch.]

Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6035/
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/6084/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
H A Dtraps.cdiff 83e4da1e Mon Oct 07 17:39:31 MDT 2013 Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> MIPS: Print correct PC in trace dump after NMI exception

An NMI exception delivered from YAMON delivers the PC in ErrorPC
instead of EPC. It's also necessary to clear the Status.BEV
bit for the page fault exception handler to work properly.

[ralf@linux-mips: Let the assembler do the loading of the mask value rather
than the convoluted explicit %hi/%lo manual relocation sequence from the
original patch.]

Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6035/
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/6084/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
/linux-master/drivers/mmc/core/
H A Dcore.hdiff 6035d973 Mon Jan 14 12:28:17 MST 2013 Konstantin Dorfman <kdorfman@codeaurora.org> mmc: fix async request mechanism for sequential read scenarios

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
H A Dbus.cdiff 6035d973 Mon Jan 14 12:28:17 MST 2013 Konstantin Dorfman <kdorfman@codeaurora.org> mmc: fix async request mechanism for sequential read scenarios

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
H A Dcore.cdiff 6035d973 Mon Jan 14 12:28:17 MST 2013 Konstantin Dorfman <kdorfman@codeaurora.org> mmc: fix async request mechanism for sequential read scenarios

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
/linux-master/fs/ext4/
H A Dext4_jbd2.cdiff 298b5c52 Fri Dec 24 03:03:41 MST 2021 Ye Bin <yebin10@huawei.com> ext4: fix null-ptr-deref in '__ext4_journal_ensure_credits'

We got issue as follows when run syzkaller test:
[ 1901.130043] EXT4-fs error (device vda): ext4_remount:5624: comm syz-executor.5: Abort forced by user
[ 1901.130901] Aborting journal on device vda-8.
[ 1901.131437] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.16: Detected aborted journal
[ 1901.131566] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.11: Detected aborted journal
[ 1901.132586] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.18: Detected aborted journal
[ 1901.132751] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.9: Detected aborted journal
[ 1901.136149] EXT4-fs error (device vda) in ext4_reserve_inode_write:6035: Journal has aborted
[ 1901.136837] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-fuzzer: Detected aborted journal
[ 1901.136915] ==================================================================
[ 1901.138175] BUG: KASAN: null-ptr-deref in __ext4_journal_ensure_credits+0x74/0x140 [ext4]
[ 1901.138343] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.13: Detected aborted journal
[ 1901.138398] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.1: Detected aborted journal
[ 1901.138808] Read of size 8 at addr 0000000000000000 by task syz-executor.17/968
[ 1901.138817]
[ 1901.138852] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.30: Detected aborted journal
[ 1901.144779] CPU: 1 PID: 968 Comm: syz-executor.17 Not tainted 4.19.90-vhulk2111.1.0.h893.eulerosv2r10.aarch64+ #1
[ 1901.146479] Hardware name: linux,dummy-virt (DT)
[ 1901.147317] Call trace:
[ 1901.147552] dump_backtrace+0x0/0x2d8
[ 1901.147898] show_stack+0x28/0x38
[ 1901.148215] dump_stack+0xec/0x15c
[ 1901.148746] kasan_report+0x108/0x338
[ 1901.149207] __asan_load8+0x58/0xb0
[ 1901.149753] __ext4_journal_ensure_credits+0x74/0x140 [ext4]
[ 1901.150579] ext4_xattr_delete_inode+0xe4/0x700 [ext4]
[ 1901.151316] ext4_evict_inode+0x524/0xba8 [ext4]
[ 1901.151985] evict+0x1a4/0x378
[ 1901.152353] iput+0x310/0x428
[ 1901.152733] do_unlinkat+0x260/0x428
[ 1901.153056] __arm64_sys_unlinkat+0x6c/0xc0
[ 1901.153455] el0_svc_common+0xc8/0x320
[ 1901.153799] el0_svc_handler+0xf8/0x160
[ 1901.154265] el0_svc+0x10/0x218
[ 1901.154682] ==================================================================

This issue may happens like this:
Process1 Process2
ext4_evict_inode
ext4_journal_start
ext4_truncate
ext4_ind_truncate
ext4_free_branches
ext4_ind_truncate_ensure_credits
ext4_journal_ensure_credits_fn
ext4_journal_restart
handle->h_transaction = NULL;
mount -o remount,abort /mnt
-> trigger JBD abort
start_this_handle -> will return failed
ext4_xattr_delete_inode
ext4_journal_ensure_credits
ext4_journal_ensure_credits_fn
__ext4_journal_ensure_credits
jbd2_handle_buffer_credits
journal = handle->h_transaction->t_journal; ->null-ptr-deref

Now, indirect truncate process didn't handle error. To solve this issue
maybe simply add check handle is abort in '__ext4_journal_ensure_credits'
is enough, and i also think this is necessary.

Cc: stable@kernel.org
Signed-off-by: Ye Bin <yebin10@huawei.com>
Link: https://lore.kernel.org/r/20211224100341.3299128-1-yebin10@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/linux-master/include/linux/
H A Dima.hdiff 6035a27b Fri Jun 08 11:40:10 MDT 2018 Al Viro <viro@zeniv.linux.org.uk> IMA: don't propagate opened through the entire thing

just check ->f_mode in ima_appraise_measurement()

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
/linux-master/sound/soc/codecs/
H A Dtlv320aic3x.cdiff 6035bbcf Mon Feb 06 12:19:13 MST 2012 Mark Brown <broonie@opensource.wolfsonmicro.com> ASoC: tlv320aic3x: Remove even more unused code

Now that we're not implementing GPIO or microphone detection support
there's no users for the read() function any more.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
/linux-master/security/integrity/ima/
H A Dima.hdiff 6035a27b Fri Jun 08 11:40:10 MDT 2018 Al Viro <viro@zeniv.linux.org.uk> IMA: don't propagate opened through the entire thing

just check ->f_mode in ima_appraise_measurement()

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
H A Dima_appraise.cdiff 6035a27b Fri Jun 08 11:40:10 MDT 2018 Al Viro <viro@zeniv.linux.org.uk> IMA: don't propagate opened through the entire thing

just check ->f_mode in ima_appraise_measurement()

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
H A Dima_main.cdiff 6035a27b Fri Jun 08 11:40:10 MDT 2018 Al Viro <viro@zeniv.linux.org.uk> IMA: don't propagate opened through the entire thing

just check ->f_mode in ima_appraise_measurement()

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
/linux-master/tools/perf/util/
H A Dcs-etm.cdiff 6035b680 Wed Jul 11 01:45:43 MDT 2018 Leo Yan <leo.yan@linaro.org> perf cs-etm: Support dummy address value for CS_ETM_TRACE_ON packet

For CS_ETM_TRACE_ON packet, its fields 'packet->start_addr' and
'packet->end_addr' equal to 0xdeadbeefdeadbeefUL which are emitted in
the decoder layer as dummy value, but the dummy value is pointless for
branch sample when we use 'perf script' command to check program flow.

This patch is a preparation to support CS_ETM_TRACE_ON packet for branch
sample, it converts the dummy address value to zero for more readable;
this is accomplished by cs_etm__last_executed_instr() and
cs_etm__first_executed_instr(). The later one is a new function
introduced by this patch.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kim Phillips <kim.phillips@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Walker <robert.walker@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1531295145-596-5-git-send-email-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
/linux-master/fs/nfsd/
H A Dvfs.cdiff 6035a27b Fri Jun 08 11:40:10 MDT 2018 Al Viro <viro@zeniv.linux.org.uk> IMA: don't propagate opened through the entire thing

just check ->f_mode in ima_appraise_measurement()

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
/linux-master/drivers/scsi/
H A Dsd.cdiff 4521428c Sat Sep 11 06:11:59 MDT 2021 Heiner Kallweit <hkallweit1@gmail.com> scsi: sd: Make sd_spinup_disk() less noisy

sd_spinup_disk() is a little bit noisy after commit 848ade90ba9c ("scsi:
sd: Do not exit sd_spinup_disk() quietly"):

scsi 0:0:0:0: Direct-Access Multiple Card Reader 1.00 PQ: 0 ANSI: 0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] Media removed, stopped polling
sd 0:0:0:0: [sda] Media removed, stopped polling
sd 0:0:0:0: [sda] Attached SCSI removable disk
sd 0:0:0:0: [sda] Media removed, stopped polling

There's not really a benefit in printing the same message multiple
times. Therefore print it only if media_present was previously set.

Link: https://lore.kernel.org/r/a2d0a249-6035-9697-626a-e14ec50ef6ee@gmail.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
/linux-master/fs/
H A Dnamei.cdiff 6035a27b Fri Jun 08 11:40:10 MDT 2018 Al Viro <viro@zeniv.linux.org.uk> IMA: don't propagate opened through the entire thing

just check ->f_mode in ima_appraise_measurement()

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
/linux-master/arch/x86/kvm/
H A Dx86.cdiff 63f42e02 Wed Jan 12 00:39:18 MST 2011 Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> KVM: fix rcu usage warning in kvm_arch_vcpu_ioctl_set_sregs()

Fix:

[ 1001.499596] ===================================================
[ 1001.499599] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 1001.499601] ---------------------------------------------------
[ 1001.499604] include/linux/kvm_host.h:301 invoked rcu_dereference_check() without protection!
......
[ 1001.499636] Pid: 6035, comm: qemu-system-x86 Not tainted 2.6.37-rc6+ #62
[ 1001.499638] Call Trace:
[ 1001.499644] [] lockdep_rcu_dereference+0x9d/0xa5
[ 1001.499653] [] gfn_to_memslot+0x8d/0xc8 [kvm]
[ 1001.499661] [] gfn_to_hva+0x16/0x3f [kvm]
[ 1001.499669] [] kvm_read_guest_page+0x1e/0x5e [kvm]
[ 1001.499681] [] kvm_read_guest_page_mmu+0x53/0x5e [kvm]
[ 1001.499699] [] load_pdptrs+0x3f/0x9c [kvm]
[ 1001.499705] [] ? vmx_set_cr0+0x507/0x517 [kvm_intel]
[ 1001.499717] [] kvm_arch_vcpu_ioctl_set_sregs+0x1f3/0x3c0 [kvm]
[ 1001.499727] [] kvm_vcpu_ioctl+0x6a5/0xbc5 [kvm]

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>

Completed in 1801 milliseconds