Re: userspace vs. kernelspace address
On Fri, Jan 28, 2005 at 01:40:51PM -0800, Rock Gordon wrote: > Hi everbody, > > Thanks for your replies. > > However I think my copy_to_user and copy_from_user are > failing since the kernel-mode thread is copying data > into another process's address space, and I am not > sure how to do this. Do the get_fs() and set_fs() > combinations let you do that? If not, then how do I do My idea is on kernel thread is limited. But I think it is not possible to any userspace address from any kernel thread because they do not have access to it. Their proc_struct->mm field is empty. I am not sure whether set_fs and get_fs help in this case. HTH, Om - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xfs integer overflow in kernel >=4.4.8
Hello, I have attached the output of my findings, with the help of others. Initially reported on Gentoo Bugzilla here: https://bugs.gentoo.org/show_bug.cgi?id=584332 Thanks in advance, be well. emese, sorry for the multiple CC's, also spender's bouncing my mail for not having a valid hostname set. [ 177.145398] PAX: end: index: 0 [ 177.145400] PAX: size overflow detected in function invalidate_inode_pages2_range mm/truncate.c:609 cicus.121_227 max, count: 5, decl: un map_mapping_range; num: 3; context: fndecl; [ 177.145532] CPU: 2 PID: 3672 Comm: xfs_fsr Not tainted 4.7.10-hardened #2 [ 177.145533] Hardware name: FUJITSU D3417-B1/D3417-B1, BIOS V5.0.0.11 R1.15.0.SR.1 for D3417-B1x 07/19/2016 [ 177.145534] 8113abcf 44c84602ff0d519d c9001227bb40 [ 177.145535] 814e8245 0261 44c84602ff0d519d 81e07e6e [ 177.145536] 81e07e98 c9001227bb70 81222869 ea0040b887c0 [ 177.145538] Call Trace: [ 177.145542] [] ? dump_stack_print_info+0x94/0xab [ 177.145545] [] dump_stack+0x74/0xbb [ 177.145546] [] report_size_overflow+0x3d/0x80 [ 177.145549] [] invalidate_inode_pages2_range+0x2ac/0x559 [ 177.145550] [] invalidate_inode_pages2+0x18/0x28 [ 177.145551] [] ? invalidate_inode_pages2+0x18/0x28 [ 177.145552] [] xfs_file_read_iter+0x181/0x232 [ 177.145554] [] __vfs_read+0x12b/0x173 [ 177.145556] [] vfs_read+0x14c/0x210 [ 177.145557] [] sys_read+0x61/0xc0 [ 177.145558] [] ? sys_read+0x61/0xc0 [ 177.145561] [] entry_SYSCALL_64_fastpath+0x1a/0xbd [ 177.145563] [] ? entry_SYSCALL_64_fastpath+0x4d/0xbd [ 177.185050] PAX: end: index: 54 [ 177.185052] PAX: size overflow detected in function invalidate_inode_pages2_range mm/truncate.c:609 cicus.121_227 max, count: 5, decl: un map_mapping_range; num: 3; context: fndecl; [ 177.185210] CPU: 0 PID: 3672 Comm: xfs_fsr Not tainted 4.7.10-hardened #2 [ 177.185210] Hardware name: FUJITSU D3417-B1/D3417-B1, BIOS V5.0.0.11 R1.15.0.SR.1 for D3417-B1x 07/19/2016 [ 177.185211] 8113abcf 44c84602ff0d519d c9001227bb40 [ 177.185213] 814e8245 0261 44c84602ff0d519d 81e07e6e [ 177.185214] 81e07e98 c9001227bb70 81222869 ea0002cfcb00 [ 177.185216] Call Trace: [ 177.185220] [] ? dump_stack_print_info+0x94/0xab [ 177.185222] [] dump_stack+0x74/0xbb [ 177.185225] [] report_size_overflow+0x3d/0x80 [ 177.185227] [] invalidate_inode_pages2_range+0x2ac/0x559 [ 177.185228] [] invalidate_inode_pages2+0x18/0x28 [ 177.185229] [] ? invalidate_inode_pages2+0x18/0x28 [ 177.185231] [] xfs_file_read_iter+0x181/0x232 [ 177.185232] [] __vfs_read+0x12b/0x173 [ 177.185234] [] vfs_read+0x14c/0x210 [ 177.185235] [] sys_read+0x61/0xc0 [ 177.185236] [] ? sys_read+0x61/0xc0 [ 177.185239] [] entry_SYSCALL_64_fastpath+0x1a/0xbd [ 177.187000] PAX: end: index: 4a [ 177.187001] PAX: size overflow detected in function invalidate_inode_pages2_range mm/truncate.c:609 cicus.121_227 max, count: 5, decl: un map_mapping_range; num: 3; context: fndecl; [ 177.187193] CPU: 0 PID: 3672 Comm: xfs_fsr Not tainted 4.7.10-hardened #2 [ 177.187193] Hardware name: FUJITSU D3417-B1/D3417-B1, BIOS V5.0.0.11 R1.15.0.SR.1 for D3417-B1x 07/19/2016 [ 177.187194] 8113abcf 44c84602ff0d519d c9001227bae0 [ 177.187195] 814e8245 0261 44c84602ff0d519d 81e07e6e [ 177.187197] 81e07e98 c9001227bb10 81222869 ea0002cb6bc0 [ 177.187212] Call Trace: [ 177.187215] [] ? dump_stack_print_info+0x94/0xab [ 177.187217] [] dump_stack+0x74/0xbb [ 177.187220] [] report_size_overflow+0x3d/0x80 [ 177.187221] [] invalidate_inode_pages2_range+0x2ac/0x559 [ 177.187223] [] invalidate_inode_pages2+0x18/0x28 [ 177.187224] [] ? invalidate_inode_pages2+0x18/0x28 [ 177.187225] [] xfs_file_read_iter+0x181/0x232 [ 177.187227] [] __vfs_read+0x12b/0x173 [ 177.187228] [] vfs_read+0x14c/0x210 [ 177.187230] [] sys_read+0x61/0xc0 [ 177.187231] [] ? sys_read+0x61/0xc0 [ 177.187233] [] entry_SYSCALL_64_fastpath+0x1a/0xbd [ 177.187235] [] ? entry_SYSCALL_64_fastpath+0x4d/0xbd [ 177.188987] PAX: end: index: 51 [ 177.191533] PAX: end: index: 51 [ 177.192782] PAX: end: index: 51
pcie Hotplug problem.
I have a machine with PCIe Hotplug capability. I am trying to run 2.6.19 and get hotplug working. It is (AMD64, Dual core, Dual processor, CK804 south bridge). The card I am trying to hotplug is based on Intel 82571EB Gigabit Ethernet Controller (rev 06) ) 1. loading pcieph crashes the system. So I am assuming pcie native hotplug is not currently supported by HW/BIOS 2. Loading acpiphp.ko gives these messages. But the cards are not visible after insertion. The (green) light does not glow. lspci does not list the inserted cards. [ 598.126985] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 598.143390] acpiphp: Slot [6] registered [ 598.144163] acpiphp: Slot [5] registered 3. If the cards were present (i.e, cold plugging) when the system boots up, lspci lists them. After modprobe-ing acpiphp.ko, pressing the attention button on the card make the status light blink for 10 sec or so and stays green. Card does not power off. (even when the corresponding ethX are down) 83:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Subsystem: Sun Microsystems Computer Corp. Unknown device f25e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- http://www.mail-archive.com/linux-newbie@vger.kernel.org/msg06757.html ) But does not help much since even acpiphp.ko does not work. Any pointers? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce global impact
On 8/26/2016 9:47 AM, Dmitry Shmidt wrote: On Fri, Aug 26, 2016 at 5:51 AM, Tejun Heo wrote: Hello, John. On Thu, Aug 25, 2016 at 07:14:07PM -0700, John Stultz wrote: Hey! Good news. This patch along with Peter's locking changes pushes the latencies down to an apparently acceptable level! Ah, that's good to hear. Please feel free to ping me if you guys wanna talk about cgroup usage in android. Thanks a lot for all your help resolving this issue! Thank you for the help. Thanks! -- tejun -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce global impact
Thank you Dimtry for sharing the patches. Update from my tests: Use-case: Android application launches. I tested the patches on android N build, i see max latency ~7ms. In my tests, the wait is due to: copy_process(fork.c) blocks all threads in __cgroup_procs_write including threads which are not part of the forking process's thread-group. Dimtry had provided a hack patch which reverts to per-process rw-sem which had max latency of ~2ms. android user-space binder library does 2 cgroup write operations per transaction, apart from the copy_process(fork.c) wait, i see pre-emption in _cgroup_procs_write causing waits. Thanks. -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] PCI: tegra: Disable PTM capabilities for EP mode
PCIe EP compliance expect PTM capabilities (ROOT_CAPABLE, RES_CAPABLE,
CLK_GRAN) to be disabled.
Signed-off-by: Om Prakash Singh
---
drivers/pci/controller/dwc/pcie-tegra194.c | 17 -
include/uapi/linux/pci_regs.h | 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
b/drivers/pci/controller/dwc/pcie-tegra194.c
index 6fa216e..a588312 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -1639,7 +1639,7 @@ static void pex_ep_event_pex_rst_deassert(struct
tegra_pcie_dw *pcie)
struct dw_pcie *pci = &pcie->pci;
struct dw_pcie_ep *ep = &pci->ep;
struct device *dev = pcie->dev;
- u32 val;
+ u32 val, ptm_cap_base = 0;
int ret;
if (pcie->ep_state == EP_STATE_ENABLED)
@@ -1760,6 +1760,21 @@ static void pex_ep_event_pex_rst_deassert(struct
tegra_pcie_dw *pcie)
PCI_CAP_ID_EXP);
clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
+ /* Disable PTM root and responder capability */
+ ptm_cap_base = dw_pcie_find_ext_capability(&pcie->pci,
+ PCI_EXT_CAP_ID_PTM);
+ if (ptm_cap_base) {
+ dw_pcie_dbi_ro_wr_en(pci);
+ val = dw_pcie_readl_dbi(pci, ptm_cap_base + PCI_PTM_CAP);
+ val &= ~PCI_PTM_CAP_ROOT;
+ dw_pcie_writel_dbi(pci, ptm_cap_base + PCI_PTM_CAP, val);
+
+ val = dw_pcie_readl_dbi(pci, ptm_cap_base + PCI_PTM_CAP);
+ val &= ~(PCI_PTM_CAP_RES | PCI_PTM_GRANULARITY_MASK);
+ dw_pcie_writel_dbi(pci, ptm_cap_base + PCI_PTM_CAP, val);
+ dw_pcie_dbi_ro_wr_dis(pci);
+ }
+
val = (ep->msi_mem_phys & MSIX_ADDR_MATCH_LOW_OFF_MASK);
val |= MSIX_ADDR_MATCH_LOW_OFF_EN;
dw_pcie_writel_dbi(pci, MSIX_ADDR_MATCH_LOW_OFF, val);
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index e709ae8..9dd6f8d 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -1050,6 +1050,7 @@
/* Precision Time Measurement */
#define PCI_PTM_CAP0x04/* PTM Capability */
#define PCI_PTM_CAP_REQ 0x0001 /* Requester capable */
+#define PCI_PTM_CAP_RES 0x0002 /* Responder capable */
#define PCI_PTM_CAP_ROOT 0x0004 /* Root capable */
#define PCI_PTM_GRANULARITY_MASK 0xFF00 /* Clock granularity */
#define PCI_PTM_CTRL 0x08/* PTM Control */
--
2.7.4
Re: [PATCH] PCI: tegra: Disable PTM capabilities for EP mode
On 3/5/2021 11:43 PM, Vidya Sagar wrote:
>
>
> On 3/5/2021 5:49 PM, Bjorn Helgaas wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On Fri, Mar 05, 2021 at 01:42:34PM +0530, Om Prakash Singh wrote:
>>> PCIe EP compliance expect PTM capabilities (ROOT_CAPABLE, RES_CAPABLE,
>>> CLK_GRAN) to be disabled.
>>
>> I guess this is just enforcing the PCIe spec requirements that only
>> Root Ports, RCRBs, and Switches are allowed to set the PTM Responder
>> Capable bit, and that the Local Clock Granularity is RsvdP if PTM Root
>> Capable is zero? (PCIe r5.0, sec 7.9.16.2)
>>
>> Should this be done more generally somewhere in the dwc code as
>> opposed to in the tegra code?
> Agree.
>
I'll take care of this in next patch version
>>
>>> Signed-off-by: Om Prakash Singh
>>> ---
>>> drivers/pci/controller/dwc/pcie-tegra194.c | 17 -
>>> include/uapi/linux/pci_regs.h | 1 +
>>> 2 files changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
>>> b/drivers/pci/controller/dwc/pcie-tegra194.c
>>> index 6fa216e..a588312 100644
>>> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
>>> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
>>> @@ -1639,7 +1639,7 @@ static void pex_ep_event_pex_rst_deassert(struct
>>> tegra_pcie_dw *pcie)
>>> struct dw_pcie *pci = &pcie->pci;
>>> struct dw_pcie_ep *ep = &pci->ep;
>>> struct device *dev = pcie->dev;
>>> - u32 val;
>>> + u32 val, ptm_cap_base = 0;
>>
>> Unnecessary init.
>>
>>> int ret;
>>>
>>> if (pcie->ep_state == EP_STATE_ENABLED)
>>> @@ -1760,6 +1760,21 @@ static void pex_ep_event_pex_rst_deassert(struct
>>> tegra_pcie_dw *pcie)
>>> PCI_CAP_ID_EXP);
>>> clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
>>>
>>> + /* Disable PTM root and responder capability */
>>> + ptm_cap_base = dw_pcie_find_ext_capability(&pcie->pci,
>>> + PCI_EXT_CAP_ID_PTM);
>>> + if (ptm_cap_base) {
>>> + dw_pcie_dbi_ro_wr_en(pci);
>>> + val = dw_pcie_readl_dbi(pci, ptm_cap_base + PCI_PTM_CAP);
>>> + val &= ~PCI_PTM_CAP_ROOT;
>>> + dw_pcie_writel_dbi(pci, ptm_cap_base + PCI_PTM_CAP, val);
>>> +
>>> + val = dw_pcie_readl_dbi(pci, ptm_cap_base + PCI_PTM_CAP);
>>> + val &= ~(PCI_PTM_CAP_RES | PCI_PTM_GRANULARITY_MASK);
> Why can't this be clubbed with "val &= ~PCI_PTM_CAP_ROOT;" ?
>
This cannot be clubbed as PTM root capability needs to disable first before
disabling responded capability
>>> + dw_pcie_writel_dbi(pci, ptm_cap_base + PCI_PTM_CAP, val);
>>> + dw_pcie_dbi_ro_wr_dis(pci);
>>> + }
>>> +
>>> val = (ep->msi_mem_phys & MSIX_ADDR_MATCH_LOW_OFF_MASK);
>>> val |= MSIX_ADDR_MATCH_LOW_OFF_EN;
>>> dw_pcie_writel_dbi(pci, MSIX_ADDR_MATCH_LOW_OFF, val);
>>> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
>>> index e709ae8..9dd6f8d 100644
>>> --- a/include/uapi/linux/pci_regs.h
>>> +++ b/include/uapi/linux/pci_regs.h
>>> @@ -1050,6 +1050,7 @@
>>> /* Precision Time Measurement */
>>> #define PCI_PTM_CAP 0x04 /* PTM Capability */
>>> #define PCI_PTM_CAP_REQ 0x0001 /* Requester capable */
>>> +#define PCI_PTM_CAP_RES 0x0002 /* Responder capable */
>>> #define PCI_PTM_CAP_ROOT 0x0004 /* Root capable */
>>> #define PCI_PTM_GRANULARITY_MASK 0xFF00 /* Clock granularity */
>>> #define PCI_PTM_CTRL 0x08 /* PTM Control */
>>> --
>>> 2.7.4
>>>
