Some interrupts (such as the rescheduling IPI) rely on not going through
the irq_enter()/irq_exit() calls. To distinguish such interrupts, add
a new IRQ flag that allows the low-level handling code to sidestep the
enter()/exit() calls.
Only the architecture code is expected to use this. It will do the wrong
thing on normal interrupts. Note that this is a band-aid until we can
move to some more correct infrastructure (such as kernel/entry/common.c).
Bug: 191808738
Link: https://lore.kernel.org/lkml/20201124141449.572446-3-maz@kernel.org/
Change-Id: I0609a8b689219ba9e769c8b9f7fcf1e77a0ff1ca
Signed-off-by: Marc Zyngier <maz@kernel.org>
[minor port to 5.10]
Signed-off-by: Stephen Dickey <dickey@codeaurora.org>
Some arch-specific flags need to be set/cleared, but not exposed to
random device drivers. Introduce a new helper (__irq_modify_status())
that takes an arbitrary mask, and rewrite irq_modify_status() to use
this new helper.
No functionnal change.
Bug: 191808738
Link: https://lore.kernel.org/lkml/20201124141449.572446-5-maz@kernel.org/
Change-Id: I2c2c0d6599d0ab39fad22462bf4c87694362fba8
Signed-off-by: Marc Zyngier <maz@kernel.org>
[minor port to 5.10]
Signed-off-by: Stephen Dickey <dickey@codeaurora.org>
Add the vendor hook to qos.c, because of some special cases related to
our feature. we add the hook at freq_qos_add_request and remove_request
to make sure we can go to our own qos process logic.
Bug: 187458531
Signed-off-by: heshuai1 <heshuai1@xiaomi.com>
Change-Id: I1fb8fd6134432ecfb44ad242c66ccd8280ab9b43
Map the permission gating RTM_GETNEIGH/RTM_GETNEIGHTBL messages to a
new permission so that it can be distinguished from the other netlink
route permissions in selinux policy. The new permission is triggered by
a flag set in system images T and up.
This change is intended to be backported to all kernels that a T system
image can run on top of.
Bug: 171572148
Test: atest NetworkInterfaceTest
Test: atest CtsSelinuxTargetSdkCurrentTestCases
Test: atest bionic-unit-tests-static
Test: On Cuttlefish, run combinations of:
- Policy bit set or omitted (see https://r.android.com/1701847)
- This patch applied or omitted
- App having nlmsg_readneigh permission or not
Verify that only the combination of this patch + the policy bit being
set + the app not having the nlmsg_readneigh permission prevents the
app from sending RTM_GETNEIGH messages.
Change-Id: I4bcfce4decb34ea9388eeedfc4be67403de8a980
Signed-off-by: Bram Bonné <brambonne@google.com>
(cherry picked from commit fac07550bd)
When CONFIG_DMABUF_SYSFS_STATS=y, dma_buf_do_mmap() will call a
dma-bufs mmap() callback before overriding the open() and close()
callbacks for the dma-buf's vm_operations_stuct, such that
dma_buf_vma_open() and dma_buf_vma_close() are used instead. Each of
the two aforementioend callbacks assumes that the vma->vm_file pointer
they use points to a dma-buf file.
However, it is possible that during the invocation of the dma-buf's
mmap() callback, that the vma->vm_file pointer changes to store
something other than a dma-buf file (it is permissible to do this so
long as certain conditions are met, see the callsite of call_mmap in
mm/mmap.c as of commit a2e00b4b5d ("FROMGIT: mm/slub: add taint
after the errors are printed"). This means that when
dma_buf_vma_open() and dma_buf_vma_close() run, that their accesses to
vma->vm_file will cease to be semantically valid.
Accordingly, only override the open() and close() vm_operations_struct
callbacks if a dma-buf's mmap() callback preserves the vma->vm_file
across the mmap() callback.
Bug: 191742286
Fixes: 9132fbe545 ("ANDROID: dmabuf: Add mmap_count to struct dmabuf")
Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
Change-Id: I4f80ade7f0bc85e2cb9219478550dcb6bbb29f3e
Mediatek UFS reset function relies on Reset Control provided by
reset-ti-syscon. To make Mediatek Reset Control work properly, select
reset-ti-syscon to ensure it is being built.
In addition, establish device_link to wait until reset-ti-syscon
initialization is complete during UFS probing.
Bug: 191731858
Change-Id: I14f20e0a5ae5b2fed213db71729180dfe43d0034
(cherry picked from commit de48898d0c
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Link: https://lore.kernel.org/r/1622601720-22466-1-git-send-email-peter.wang@mediatek.com
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
add this information to help user to find ashmem problem.
ashmem leak scenario:
-000|fd = ashmem_create_region
-001|mmap and pagefault
-002|munmap
-003|forget close(fd) <---- which lead to ashmem leak
Link: https://lore.kernel.org/patchwork/patch/1448571
Bug: 191291741
Signed-off-by: liuhailong <liuhailong@oppo.com>
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I68ac5a42357eff11056c9ed1207da07fefbea77d
Set KMI_GENERATION=7 for 6/18 KMI update
Leaf changes summary: 2925 artifacts changed
Changed leaf types summary: 24 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 2847 Changed, 3 Added functions
Removed/Changed/Added variables summary: 0 Removed, 51 Changed, 0 Added variable
3 Added functions:
[A] 'function void pci_disable_sriov(pci_dev*)'
[A] 'function int pci_enable_sriov(pci_dev*, int)'
[A] 'function int pci_vfs_assigned(pci_dev*)'
2847 functions with some sub-type change:
[C] 'function int __traceiter_android_vh_gic_resume(void*, irq_domain*, void*)' at gic.h:15:1 has some sub-type changes:
CRC (modversions) changed from 0x79c6efed to 0xd99a1ac6
parameter 3 of type 'void*' was removed
parameter 2 of type 'irq_domain*' changed:
pointer type changed from: 'irq_domain*' to: 'gic_chip_data*'
[C] 'function void* PDE_DATA(const inode*)' at proc_fs.h:112:1 has some sub-type changes:
CRC (modversions) changed from 0x121116eb to 0x1c3ef274
[C] 'function void __ClearPageMovable(page*)' at compaction.c:138:1 has some sub-type changes:
CRC (modversions) changed from 0xc952c645 to 0xdc28d620
[C] 'function void __SetPageMovable(page*, address_space*)' at compaction.c:130:1 has some sub-type changes:
CRC (modversions) changed from 0x6c94b8ab to 0xd7b7b883
... 2843 omitted; 2846 symbols have only CRC changes
51 Changed variables:
[C] 'pglist_data contig_page_data' was changed at memblock.c:96:1:
CRC (modversions) changed from 0x1f395adc to 0x7ce0db01
type of variable changed:
type size hasn't changed
1 data member insertion:
'bool proactive_compact_trigger', at offset 41152 (in bits) at mmzone.h:786:1
there are data member changes:
'unsigned long int totalreserve_pages' offset changed (by +64 bits)
3752 impacted interfaces
[C] 'bus_type amba_bustype' was changed at bus.c:215:1:
CRC (modversions) changed from 0x1782f569 to 0x13c06cac
[C] 'neigh_table arp_tbl' was changed at arp.c:152:1:
CRC (modversions) changed from 0x832f8bb5 to 0x56697f62
[C] 'const address_space_operations balloon_aops' was changed at balloon_compaction.c:253:1:
CRC (modversions) changed from 0x31e6cab1 to 0xf0207a10
... 47 omitted; 50 symbols have only CRC changes
'struct dev_pm_qos_request at pm_qos.h:107:1' changed (indirectly):
type size changed from 576 to 704 (in bits)
there are data member changes:
type 'union {plist_node pnode; pm_qos_flags_request flr; freq_qos_request freq;}' of 'dev_pm_qos_request::data' changed:
type size changed from 448 to 576 (in bits)
there are data member changes:
type 'struct freq_qos_request' of '__anonymous_union__::freq' changed:
type size changed from 448 to 576 (in bits)
1 data member insertion:
'u64 android_oem_data1[2]', at offset 448 (in bits) at pm_qos.h:96:1
3755 impacted interfaces
'device* dev' offset changed (by +128 bits)
3752 impacted interfaces
'struct devfreq at devfreq.h:172:1' changed (indirectly):
type size changed from 16512 to 16768 (in bits)
there are data member changes:
type 'struct dev_pm_qos_request' of 'devfreq::user_min_freq_req' changed, as reported earlier
type 'struct dev_pm_qos_request' of 'devfreq::user_max_freq_req' changed, as reported earlier
and offset changed from 9152 to 9280 (in bits) (by +128 bits)
10 ('unsigned long int scaling_min_freq' .. 'notifier_block nb_max') offsets changed (by +256 bits)
59 impacted interfaces
'struct driver_info at usbnet.h:94:1' changed:
type size changed from 1152 to 1280 (in bits)
2 data member insertions:
'u64 android_kabi_reserved1', at offset 1152 (in bits) at usbnet.h:183:1
'u64 android_kabi_reserved2', at offset 1216 (in bits) at usbnet.h:184:1
10 impacted interfaces
'struct freq_qos_request at pm_qos.h:92:1' changed:
details were reported earlier
'struct hc_driver at hcd.h:249:1' changed:
type size changed from 2880 to 3136 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 2880 (in bits) at hcd.h:419:1
'u64 android_kabi_reserved2', at offset 2944 (in bits) at hcd.h:420:1
'u64 android_kabi_reserved3', at offset 3008 (in bits) at hcd.h:421:1
'u64 android_kabi_reserved4', at offset 3072 (in bits) at hcd.h:422:1
43 impacted interfaces
'struct pci_dev at pci.h:310:1' changed:
type size changed from 19328 to 24768 (in bits)
3 data member insertions:
'union {pci_sriov* sriov; pci_dev* physfn;}', at offset 24128 (in bits) at pci.h:479:1
'u16 ats_cap', at offset 24192 (in bits) at pci.h:483:1
'u8 ats_stu', at offset 24208 (in bits) at pci.h:484:1
there are data member changes:
type 'resource[11]' of 'pci_dev::resource' changed:
type name changed from 'resource[11]' to 'resource[17]'
array type size changed from 8448 to 13056
array type subrange 1 changed length from 11 to 17
7 ('bool match_driver' .. 'int rom_attr_enabled') offsets changed (by +4608 bits)
type 'bin_attribute*[11]' of 'pci_dev::res_attr' changed:
type name changed from 'bin_attribute*[11]' to 'bin_attribute*[17]'
array type size changed from 704 to 1088
array type subrange 1 changed length from 11 to 17
and offset changed from 17216 to 21824 (in bits) (by +4608 bits)
type 'bin_attribute*[11]' of 'pci_dev::res_attr_wc' changed:
type name changed from 'bin_attribute*[11]' to 'bin_attribute*[17]'
array type size changed from 704 to 1088
array type subrange 1 changed length from 11 to 17
and offset changed from 17920 to 22912 (in bits) (by +4992 bits)
2 ('const attribute_group** msi_irq_groups' .. 'pci_vpd* vpd') offsets changed (by +5376 bits)
'u16 acs_cap' offset changed (by +5472 bits)
8 ('phys_addr_t rom' .. 'u64 android_kabi_reserved4') offsets changed (by +5440 bits)
426 impacted interfaces
'struct pglist_data at mmzone.h:729:1' changed:
details were reported earlier
'struct snd_compr at compress_driver.h:146:1' changed:
type size changed from 7168 to 7808 (in bits)
3 data member insertions:
'char id[64]', at offset 7136 (in bits) at compress_driver.h:157:1
'snd_info_entry* proc_root', at offset 7680 (in bits) at compress_driver.h:158:1
'snd_info_entry* proc_info_entry', at offset 7744 (in bits) at compress_driver.h:159:1
70 impacted interfaces
'struct snd_pcm at pcm.h:509:1' changed (indirectly):
type size changed from 15680 to 15808 (in bits)
there are data member changes:
'snd_pcm_str streams[2]' size changed from 13440 to 13568 (in bits) (by +128 bits)
7 ('mutex open_mutex' .. 'bool no_device_suspend') offsets changed (by +128 bits)
97 impacted interfaces
'struct snd_pcm_str at pcm.h:488:1' changed:
type size changed from 6720 to 6784 (in bits)
1 data member insertion:
'snd_info_entry* proc_root', at offset 256 (in bits) at pcm.h:500:1
there are data member changes:
2 ('snd_kcontrol* chmap_kctl' .. 'device dev') offsets changed (by +64 bits)
97 impacted interfaces
'struct snd_pcm_substream at pcm.h:442:1' changed:
type size changed from 2944 to 3008 (in bits)
1 data member insertion:
'snd_info_entry* proc_root', at offset 2880 (in bits) at pcm.h:478:1
97 impacted interfaces
'struct tcpm_port at tcpm.c:298:1' changed:
type size changed from 99328 to 99520 (in bits)
2 data member insertions:
'u32 snk_vdo_v1[6]', at offset 8768 (in bits) at tcpm.c:405:1
'unsigned int nr_snk_vdo_v1', at offset 8960 (in bits) at tcpm.c:406:1
there are data member changes:
8 ('u32 snk_vdo[6]' .. 'u32 supply_voltage') offsets changed (by +224 bits)
32 ('power_supply* psy' .. 'u8* logbuffer[1024]') offsets changed (by +192 bits)
17 impacted interfaces
'struct ufs_hba at ufshcd.h:720:1' changed:
type size changed from 34176 to 35328 (in bits)
1 data member insertion:
'ufs_hba_monitor monitor', at offset 32320 (in bits) at ufshcd.h:866:1
there are data member changes:
5 ('ufs_crypto_capabilities crypto_capabilities' .. 'dentry* debugfs_root') offsets changed (by +1152 bits)
37 impacted interfaces
'struct ufshcd_lrb at ufshcd.h:193:1' changed:
type size hasn't changed
1 data member deletion:
'bool in_use', at offset 1096 (in bits) at ufshcd.h:221:1
37 impacted interfaces
'struct urb at usb.h:1563:1' changed:
type size changed from 1472 to 1728 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 1472 (in bits) at usb.h:1625:1
'u64 android_kabi_reserved2', at offset 1536 (in bits) at usb.h:1626:1
'u64 android_kabi_reserved3', at offset 1600 (in bits) at usb.h:1627:1
'u64 android_kabi_reserved4', at offset 1664 (in bits) at usb.h:1628:1
there are data member changes:
'usb_iso_packet_descriptor iso_frame_desc[]' offset changed (by +256 bits)
62 impacted interfaces
'struct usb_bus at usb.h:424:1' changed:
type size changed from 1152 to 1408 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 1152 (in bits) at usb.h:480:1
'u64 android_kabi_reserved2', at offset 1216 (in bits) at usb.h:481:1
'u64 android_kabi_reserved3', at offset 1280 (in bits) at usb.h:482:1
'u64 android_kabi_reserved4', at offset 1344 (in bits) at usb.h:483:1
86 impacted interfaces
'struct usb_device at usb.h:631:1' changed:
type size changed from 11456 to 11712 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 11456 (in bits) at usb.h:729:1
'u64 android_kabi_reserved2', at offset 11520 (in bits) at usb.h:730:1
'u64 android_kabi_reserved3', at offset 11584 (in bits) at usb.h:731:1
'u64 android_kabi_reserved4', at offset 11648 (in bits) at usb.h:732:1
86 impacted interfaces
'struct usb_driver at usb.h:1186:1' changed:
type size changed from 2176 to 2432 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 2176 (in bits) at usb.h:1235:1
'u64 android_kabi_reserved2', at offset 2240 (in bits) at usb.h:1236:1
'u64 android_kabi_reserved3', at offset 2304 (in bits) at usb.h:1237:1
'u64 android_kabi_reserved4', at offset 2368 (in bits) at usb.h:1238:1
2 impacted interfaces
'struct usb_hcd at hcd.h:81:1' changed:
type size changed from 4992 to 5504 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 5248 (in bits) at hcd.h:229:1
'u64 android_kabi_reserved2', at offset 5312 (in bits) at hcd.h:230:1
'u64 android_kabi_reserved3', at offset 5376 (in bits) at hcd.h:231:1
'u64 android_kabi_reserved4', at offset 5440 (in bits) at hcd.h:232:1
there are data member changes:
type 'struct usb_bus' of 'usb_hcd::self' changed, as reported earlier
27 ('kref' .. 'gen_pool* localmem_pool') offsets changed (by +256 bits)
'unsigned long int hcd_priv[]' offset changed (by +512 bits)
43 impacted interfaces
'struct usb_host_bos at usb.h:396:1' changed:
type size changed from 384 to 640 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 384 (in bits) at usb.h:412:1
'u64 android_kabi_reserved2', at offset 448 (in bits) at usb.h:413:1
'u64 android_kabi_reserved3', at offset 512 (in bits) at usb.h:414:1
'u64 android_kabi_reserved4', at offset 576 (in bits) at usb.h:415:1
86 impacted interfaces
'struct usb_interface at usb.h:232:1' changed:
type size changed from 7104 to 7360 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 7104 (in bits) at usb.h:262:1
'u64 android_kabi_reserved2', at offset 7168 (in bits) at usb.h:263:1
'u64 android_kabi_reserved3', at offset 7232 (in bits) at usb.h:264:1
'u64 android_kabi_reserved4', at offset 7296 (in bits) at usb.h:265:1
94 impacted interfaces
'struct usb_tt at hcd.h:554:1' changed:
type size changed from 640 to 896 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 640 (in bits) at hcd.h:575:1
'u64 android_kabi_reserved2', at offset 704 (in bits) at hcd.h:576:1
'u64 android_kabi_reserved3', at offset 768 (in bits) at hcd.h:577:1
'u64 android_kabi_reserved4', at offset 832 (in bits) at hcd.h:578:1
86 impacted interfaces
'struct usbnet at usbnet.h:27:1' changed:
type size changed from 5120 to 5376 (in bits)
4 data member insertions:
'u64 android_kabi_reserved1', at offset 5120 (in bits) at usbnet.h:89:1
'u64 android_kabi_reserved2', at offset 5184 (in bits) at usbnet.h:90:1
'u64 android_kabi_reserved3', at offset 5248 (in bits) at usbnet.h:91:1
'u64 android_kabi_reserved4', at offset 5312 (in bits) at usbnet.h:92:1
10 impacted interfaces
'struct vm_fault at mm.h:528:1' changed:
type size changed from 1088 to 1216 (in bits)
1 data member insertion:
'u64 android_oem_data1[2]', at offset 1088 (in bits) at mm.h:576:1
3752 impacted interfaces
Bug: 190227201
Signed-off-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1e308417a29408190a4deffa965edb454ca5c34d
For get gic_data other var, So change gic resume vendor hook para to global struct gic_data
Bug: 189518432
Signed-off-by: panwang qu <qupanwang@xiaomi.com>
Change-Id: Ie6d949ffd19fbb35fbae6facaa886ec3c2e382f8
Poisoning freed pages protects against kernel use-after-free. The
likelihood of such a bug involving kernel pages is significantly higher
than that for user pages. At the same time, poisoning freed pages can
impose a significant performance cost, which cannot always be justified
for user pages given the lower probability of finding a bug. Therefore,
disable freed user page poisoning when using HW tags. We identify
"user" pages via the flag set GFP_HIGHUSER_MOVABLE, which indicates
a strong likelihood of not being directly accessible to the kernel.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Link: https://linux-review.googlesource.com/id/I716846e2de8ef179f44e835770df7e6307be96c9
Link: https://lore.kernel.org/r/20210602235230.3928842-5-pcc@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit c275c5c6d5https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/mte)
[pcc: adjust definition of new GFP flag for compatibility with GFP_CMA]
Change-Id: I716846e2de8ef179f44e835770df7e6307be96c9
Bug: 186816853
Currently, on an anonymous page fault, the kernel allocates a zeroed
page and maps it in user space. If the mapping is tagged (PROT_MTE),
set_pte_at() additionally clears the tags. It is, however, more
efficient to clear the tags at the same time as zeroing the data on
allocation. To avoid clearing the tags on any page (which may not be
mapped as tagged), only do this if the vma flags contain VM_MTE. This
requires introducing a new GFP flag that is used to determine whether
to clear the tags.
The DC GZVA instruction with a 0 top byte (and 0 tag) requires
top-byte-ignore. Set the TCR_EL1.{TBI1,TBID1} bits irrespective of
whether KASAN_HW is enabled.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://linux-review.googlesource.com/id/Id46dc94e30fe11474f7e54f5d65e7658dbdddb26
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Link: https://lore.kernel.org/r/20210602235230.3928842-4-pcc@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 013bb59dbbhttps://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/mte)
[pcc: adjust definition of new GFP flag for compatibility with GFP_CMA; rename TCR_KASAN_HW_FLAGS to TCR_MTE_FLAGS in the old location]
Change-Id: Id46dc94e30fe11474f7e54f5d65e7658dbdddb26
Bug: 186816853
In-kernel alsa framework provides infomation by procfs for top layer
APPs and application can `cat /proc/...` to know the status.
And APPs will utilize these info to adjust their functionanilty
Bug: 189899353
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Change-Id: I89ea96073906725ae6d0308ea5d3d349ab2f1116
Current UFS IRQ handler is completely wrapped by host lock, and because
ufshcd_send_command() is also protected by host lock, when IRQ handler
fires, not only the CPU running the IRQ handler cannot send new requests,
the rest CPUs can neither. Move the host lock wrapping the IRQ handler into
specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(),
ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to further
reduce occpuation of host lock in ufshcd_transfer_req_compl(), host lock is
no longer required to call __ufshcd_transfer_req_compl(). As per test, the
optimization can bring considerable gain to random read/write performance.
Link: https://lore.kernel.org/r/1621845419-14194-3-git-send-email-cang@codeaurora.org
Cc: Stanley Chu <stanley.chu@mediatek.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Co-developed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 190637035
(cherry picked from commit a45f937110
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 5.14/scsi-staging)
[Can Guo: Resolved minor conflict in ufshcd.c and squashed with
commit eb783bb8bb picked from 5.14/scsi-staging]
Change-Id: I3e842d8bdaec700e11372b2293630bf864ec4929
Signed-off-by: Can Guo <cang@codeaurora.org>
Add a new sysfs group which has nodes to monitor data/request transfer
performance. This sysfs group has nodes showing total sectors/requests
transferred, total busy time spent and max/min/avg/sum latencies. This
group can be enhanced later to show more UFS driver layer performance
statistics data during runtime.
Link: https://lore.kernel.org/r/1619058521-35307-2-git-send-email-cang@codeaurora.org
Reviewed-by: Daejun Park <daejun7.park@samsung.com>
Acked-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 190637035
(cherry picked from commit 1d8613a23f
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 5.14/scsi-staging)
[Can Guo: Resolved minor conflict in ufshcd.c]
Change-Id: Ibf5297304b2040bf2bb73131447a2a5916d95470
Signed-off-by: Can Guo <cang@codeaurora.org>
To try to mitigate potential future USB api changes, add some padding to
the following structures:
struct usb_interface
struct usb_host_bos
struct usb_bus
struct usb_device
struct usb_driver
struct urb
struct usb_hcd
struct hc_driver
struct usb_tt
struct usbnet
struct driver_info (for usbnet driver)
Based on a patch from Oliver Neukum <oneukum@suse.de> from the SLES
kernel.
Leaf changes summary: 10 artifacts changed
Changed leaf types summary: 10 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct driver_info at usbnet.h:94:1' changed:
type size changed from 1152 to 1280 (in bits)
2 data member insertions:
'u64 driver_info::android_kabi_reserved1', at offset 1152 (in bits) at usbnet.h:183:1
'u64 driver_info::android_kabi_reserved2', at offset 1216 (in bits) at usbnet.h:184:1
10 impacted interfaces:
'struct hc_driver at hcd.h:249:1' changed:
type size changed from 2880 to 3136 (in bits)
4 data member insertions:
'u64 hc_driver::android_kabi_reserved1', at offset 2880 (in bits) at hcd.h:419:1
'u64 hc_driver::android_kabi_reserved2', at offset 2944 (in bits) at hcd.h:420:1
'u64 hc_driver::android_kabi_reserved3', at offset 3008 (in bits) at hcd.h:421:1
'u64 hc_driver::android_kabi_reserved4', at offset 3072 (in bits) at hcd.h:422:1
16 impacted interfaces:
'struct urb at usb.h:1550:1' changed:
type size changed from 1472 to 1728 (in bits)
4 data member insertions:
'u64 urb::android_kabi_reserved1', at offset 1472 (in bits) at usb.h:1613:1
'u64 urb::android_kabi_reserved2', at offset 1536 (in bits) at usb.h:1614:1
'u64 urb::android_kabi_reserved3', at offset 1600 (in bits) at usb.h:1615:1
'u64 urb::android_kabi_reserved4', at offset 1664 (in bits) at usb.h:1616:1
39 impacted interfaces:
'struct usb_bus at usb.h:424:1' changed:
type size changed from 1024 to 1280 (in bits)
4 data member insertions:
'u64 usb_bus::android_kabi_reserved1', at offset 1024 (in bits) at usb.h:480:1
'u64 usb_bus::android_kabi_reserved2', at offset 1088 (in bits) at usb.h:481:1
'u64 usb_bus::android_kabi_reserved3', at offset 1152 (in bits) at usb.h:482:1
'u64 usb_bus::android_kabi_reserved4', at offset 1216 (in bits) at usb.h:483:1
54 impacted interfaces:
'struct usb_device at usb.h:631:1' changed:
type size changed from 11712 to 11968 (in bits)
4 data member insertions:
'u64 usb_device::android_kabi_reserved1', at offset 11712 (in bits) at usb.h:728:1
'u64 usb_device::android_kabi_reserved2', at offset 11776 (in bits) at usb.h:729:1
'u64 usb_device::android_kabi_reserved3', at offset 11840 (in bits) at usb.h:730:1
'u64 usb_device::android_kabi_reserved4', at offset 11904 (in bits) at usb.h:731:1
54 impacted interfaces:
'struct usb_driver at usb.h:1183:1' changed:
type size changed from 2432 to 2688 (in bits)
4 data member insertions:
'u64 usb_driver::android_kabi_reserved1', at offset 2432 (in bits) at usb.h:1232:1
'u64 usb_driver::android_kabi_reserved2', at offset 2496 (in bits) at usb.h:1233:1
'u64 usb_driver::android_kabi_reserved3', at offset 2560 (in bits) at usb.h:1234:1
'u64 usb_driver::android_kabi_reserved4', at offset 2624 (in bits) at usb.h:1235:1
4 impacted interfaces:
'struct usb_hcd at hcd.h:81:1' changed:
type size changed from 4736 to 5248 (in bits)
4 data member insertions:
'u64 usb_hcd::android_kabi_reserved1', at offset 4992 (in bits) at hcd.h:229:1
'u64 usb_hcd::android_kabi_reserved2', at offset 5056 (in bits) at hcd.h:230:1
'u64 usb_hcd::android_kabi_reserved3', at offset 5120 (in bits) at hcd.h:231:1
'u64 usb_hcd::android_kabi_reserved4', at offset 5184 (in bits) at hcd.h:232:1
16 impacted interfaces:
'struct usb_host_bos at usb.h:396:1' changed:
type size changed from 384 to 640 (in bits)
4 data member insertions:
'u64 usb_host_bos::android_kabi_reserved1', at offset 384 (in bits) at usb.h:412:1
'u64 usb_host_bos::android_kabi_reserved2', at offset 448 (in bits) at usb.h:413:1
'u64 usb_host_bos::android_kabi_reserved3', at offset 512 (in bits) at usb.h:414:1
'u64 usb_host_bos::android_kabi_reserved4', at offset 576 (in bits) at usb.h:415:1
54 impacted interfaces:
'struct usb_interface at usb.h:232:1' changed:
type size changed from 7360 to 7616 (in bits)
4 data member insertions:
'u64 usb_interface::android_kabi_reserved1', at offset 7360 (in bits) at usb.h:262:1
'u64 usb_interface::android_kabi_reserved2', at offset 7424 (in bits) at usb.h:263:1
'u64 usb_interface::android_kabi_reserved3', at offset 7488 (in bits) at usb.h:264:1
'u64 usb_interface::android_kabi_reserved4', at offset 7552 (in bits) at usb.h:265:1
73 impacted interfaces:
'struct usbnet at usbnet.h:27:1' changed:
type size changed from 4736 to 4992 (in bits)
4 data member insertions:
'u64 usbnet::android_kabi_reserved1', at offset 4736 (in bits) at usbnet.h:89:1
'u64 usbnet::android_kabi_reserved2', at offset 4800 (in bits) at usbnet.h:90:1
'u64 usbnet::android_kabi_reserved3', at offset 4864 (in bits) at usbnet.h:91:1
'u64 usbnet::android_kabi_reserved4', at offset 4928 (in bits) at usbnet.h:92:1
10 impacted interfaces:
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Signed-off-by: Sandeep Patil <sspatil@google.com>
Change-Id: Ie9e246d9333ac70fc9cc2b0bf7cb466a8ffdb6de
PCI_IOV[1] provides I/O virtualization for PCI devices which allows to
create virtual devices and to share a PCI device among VMs.
In order to support the feature from GKI kernel,
we need to enable PCI_IOV and PCI_ATS which is selected by PCI_IOV.
[1]: https://www.kernel.org/doc/html/latest/PCI/pci-iov-howto.html
Bug: 190460626
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I9fc883536083eaa935f207676d7b2ef8b9ec0b93
Add vendor_hooks to filemap_fault to cache page for oem's optimization.
Save the page for next time retry when VM_FAULT_RETRY returned.
Add ANDROID_OEM_DATA to vm_fault to save the page.
Bug: 188891314
Change-Id: Ibfc9ec950c3360e6f6ccb9546cab0acd89e5d316
Signed-off-by: Liangliang Li <liliangliang@vivo.com>
Currently, proactive compaction tries to get triggered for every
HPAGE_FRAG_CHECK_INTERVAL_MSEC(=500msec) even when proactive compaction
is disabled with sysctl.compaction_proactiveness = 0. This results in
kcompactd thread wakes up and goes to sleep for every 500msec with out
the need of doing proactive compaction. Though this doesn't have any
overhead, few cpu cycles can be saved by avoid of waking up kcompactd
thread for proactive compaction when it is disabled.
Bug: 186387247
Link: https://lore.kernel.org/patchwork/patch/1438213/
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Change-Id: I7e32dc0eec628df7d88d554dd325acfc9ac1ae57
The proactive compaction[1] gets triggered for every 500msec and run
compaction on the node for COMPACTION_HPAGE_ORDER (usually order-9)
pages based on the value set to sysctl.compaction_proactiveness.
Triggering the compaction for every 500msec in search of
COMPACTION_HPAGE_ORDER pages is not needed for all applications,
especially on the embedded system usecases which may have few MB's of
RAM. Enabling the proactive compaction in its state will endup in
running almost always on such systems.
Other side, proactive compaction can still be very much useful for
getting a set of higher order pages in some controllable
manner(controlled by using the sysctl.compaction_proactiveness). Thus on
systems where enabling the proactive compaction always may proove not
required, can trigger the same from user space on write to its sysctl
interface. As an example, say app launcher decide to launch the memory
heavy application which can be launched fast if it gets more higher
order pages thus launcher can prepare the system in advance by
triggering the proactive compaction from userspace.
This triggering of proactive compaction is done on a write to
sysctl.compaction_proactiveness by user.
[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=facdaa917c4d5a376d09d25865f5a863f906234a
Bug: 186387247
Link: https://lore.kernel.org/patchwork/patch/1438211/
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Change-Id: Ie5208e274b9d7e7354471bb98ff1f10becf93595
Add missing newline termination to a bunch of pr_debug()/pr_err()
Test: builds, and kernel net tests passes
Bug: 183485987
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I53eccc88c383259bc7a71ea688f728a0908fa765
Add Some necessary WIFI configs which are missing in GKI.
Bug: 188373235
Change-Id: I89b8f486137127a41b1ae07e1278bf8e44fb68f0
Signed-off-by: Orson Zhai <orson.zhai@unisoc.com>
To avoid unnecessary recompilations, mkcompile_h does not regenerate
compile.h if just the timestamp changed.
Though, if KBUILD_BUILD_TIMESTAMP is set, an explicit timestamp for the
build was requested, in which case we should not ignore it.
If a user follows the documentation for reproducible builds [1] and
defines KBUILD_BUILD_TIMESTAMP as the git commit timestamp, a clean
build will have the correct timestamp. A subsequent cherry-pick (or
amend) changes the commit timestamp and if an incremental build is done
with a different KBUILD_BUILD_TIMESTAMP now, that new value is not taken
into consideration. But it should for reproducibility.
Hence, whenever KBUILD_BUILD_TIMESTAMP is explicitly set, do not ignore
UTS_VERSION when making a decision about whether the regenerated version
of compile.h should be moved into place.
[1] https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org
Bug: 189077755
Link: https://lore.kernel.org/r/20210612141838.1073085-1-maennich@google.com
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I47a1b9e079346be82794ec93a449258e086945eb
This config option was not requested by any partner and has non-zero
overhead on process creation. Disable it.
Bug: 191150949
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ia9547c989c22246c46ed9624a0707c6369ee4de0
In the Scudo memory allocator [1] we would like to be able to detect
use-after-free vulnerabilities involving large allocations by issuing
mprotect(PROT_NONE) on the memory region used for the allocation when it
is deallocated. Later on, after the memory region has been "quarantined"
for a sufficient period of time we would like to be able to use it for
another allocation by issuing mprotect(PROT_READ|PROT_WRITE).
Before this patch, after removing the write protection, any writes to the
memory region would result in page faults and entering the copy-on-write
code path, even in the usual case where the pages are only referenced by a
single PTE, harming performance unnecessarily. Make it so that any pages
in anonymous mappings that are only referenced by a single PTE are
immediately made writable during the mprotect so that we can avoid the
page faults.
This program shows the critical syscall sequence that we intend to use in
the allocator:
#include <string.h>
#include <sys/mman.h>
enum { kSize = 131072 };
int main(int argc, char **argv) {
char *addr = (char *)mmap(0, kSize, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
for (int i = 0; i != 100000; ++i) {
memset(addr, i, kSize);
mprotect((void *)addr, kSize, PROT_NONE);
mprotect((void *)addr, kSize, PROT_READ | PROT_WRITE);
}
}
The effect of this patch on the above program was measured on a
DragonBoard 845c by taking the median real time execution time of 10 runs.
Before: 2.94s
After: 0.66s
The effect was also measured using one of the microbenchmarks that we
normally use to benchmark the allocator [2], after modifying it to make
the appropriate mprotect calls [3]. With an allocation size of 131072
bytes to trigger the allocator's "large allocation" code path the
per-iteration time was measured as follows:
Before: 27450ns
After: 6010ns
This patch means that we do more work during the mprotect call itself in
exchange for less work when the pages are accessed. In the worst case,
the pages are not accessed at all. The effect of this patch in such cases
was measured using the following program:
#include <string.h>
#include <sys/mman.h>
enum { kSize = 131072 };
int main(int argc, char **argv) {
char *addr = (char *)mmap(0, kSize, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
memset(addr, 1, kSize);
for (int i = 0; i != 100000; ++i) {
#ifdef PAGE_FAULT
memset(addr + (i * 4096) % kSize, i, 4096);
#endif
mprotect((void *)addr, kSize, PROT_NONE);
mprotect((void *)addr, kSize, PROT_READ | PROT_WRITE);
}
}
With PAGE_FAULT undefined (0 pages touched after removing write
protection) the median real time execution time of 100 runs was measured
as follows:
Before: 0.330260s
After: 0.338836s
With PAGE_FAULT defined (1 page touched) the measurements were
as follows:
Before: 0.438048s
After: 0.355661s
So it seems that even with a single page fault the new approach is faster.
I saw similar results if I adjusted the programs to use a larger mapping
size. With kSize = 1048576 I get these numbers with PAGE_FAULT undefined:
Before: 1.428988s
After: 1.512016s
i.e. around 5.5%.
And these with PAGE_FAULT defined:
Before: 1.518559s
After: 1.524417s
i.e. about the same.
What I think we may conclude from these results is that for smaller
mappings the advantage of the previous approach, although measurable, is
wiped out by a single page fault. I think we may expect that there should
be at least one access resulting in a page fault (under the previous
approach) after making the pages writable, since the program presumably
made the pages writable for a reason.
For larger mappings we may guesstimate that the new approach wins if the
density of future page faults is > 0.4%. But for the mappings that are
large enough for density to matter (not just the absolute number of page
faults) it doesn't seem like the increase in mprotect latency would be
very large relative to the total mprotect execution time.
Link: https://lkml.kernel.org/r/20210527190453.1259020-1-pcc@google.com
Link: https://linux-review.googlesource.com/id/I98d75ef90e20330c578871c87494d64b1df3f1b8
Link: [1] https://source.android.com/devices/tech/debug/scudo
Link: [2] https://cs.android.com/android/platform/superproject/+/master:bionic/benchmarks/stdlib_benchmark.cpp;l=53;drc=e8693e78711e8f45ccd2b610e4dbe0b94d551cc9
Link: [3] https://github.com/pcc/llvm-project/commit/scudo-mprotect-secondary2
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: Kostya Kortchinsky <kostyak@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit e2037f9c0c61ed6964bb1291292ae88f073a100c
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
[pcc: squashed v4->v5 diff which appeared as a separate commit: ec7563ea9f6a470e9bb532b024ce29d9474daf24]
Change-Id: Ic3994b2ec914d3f62f95c1ef338986e350e69e36
Bug: 191165850
