Merge pull request #1 from torvalds/master #483

cyberaddicted · 2017-10-28T12:23:00Z

Update upstream

KernelPRBot · 2017-10-28T12:25:07Z

Hi @louletian!

Thanks for your contribution to the Linux kernel!

Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.

Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process.

Here's what to do:

Format your contribution according to kernel requirements
Decide who to send your contribution to
Set up your system to send your contribution as an email
Send your contribution and wait for feedback

How do I format my contribution?

The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations.

Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea.

You can create patches with git format-patch.

Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary.

Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with.

Both of these are documented in the Submitting Patches documentation that is part of the kernel.

Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this.

Who do I send my contribution to?

The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes.

If you don't already know what subsystem your change belongs to, the get_maintainer.pl script in the kernel source can help you.

get_maintainer.pl will take the patch or patches you created in the previous step, and tell you who is responsible for them, and what mailing lists are used. You can also take a look at the MAINTAINERS file by hand.

Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches.

It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.)

How do I send my contribution?

Use git send-email, which will ensure that your patches are formatted in the standard manner. In order to use git send-email, you'll need to configure git to use your SMTP email server.

For more information about using git send-email, look at the Git documentation or type git help send-email. There are a number of useful guides and tutorials about git send-email that can be found on the internet.

How do I get help if I'm stuck?

Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed.

Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine.

If you can't find an answer, there are a few places you can turn:

Kernel Newbies - this website contains a lot of useful resources for new kernel developers.
The kernel documentation - see also the Documentation directory in the kernel tree.

If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers!

I sent my patch - now what?

You wait.

You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at.

Then, you keep waiting. Three things may happen:

You might get a response to your email. Often these will be comments, which may require you to make changes to your patch, or explain why your way is the best way. You should respond to these comments, and you may need to submit another revision of your patch to address the issues raised.
Your patch might be merged into the subsystem tree. Code that becomes part of Linux isn't merged into the main repository straight away - it first goes into the subsystem tree, which is managed by the subsystem maintainer. It is then batched up with a number of other changes sent to Linus for inclusion. (This process is described in some detail in the kernel development process guide).
Your patch might be ignored completely. This happens sometimes - don't take it personally. Here's what to do:
- Wait a bit more - patches often take several weeks to get a response; more if they were sent at a busy time.
- Kernel developers often silently ignore patches that break the rules. Check for obvious violations of the the Submitting Patches guidelines, the style guidelines, and any other documentation you can find about your subsystem. Check that you're sending your patch to the right place.
- Try again later. When you resend it, don't add angry commentary, as that will get your patch ignored. It might also get you silently blacklisted.

Further information

Working with the kernel development community - the official documentation for new kernel contributors

Happy hacking!

This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot.

This checks that it is not possible to bypass the total stack size check in update_stack_depth() by calling a function that uses a large amount of stack memory *before* using a large amount of stack memory in the caller. Currently, the first added testcase causes a rejection as expected, but the second testcase is (AFAICS incorrectly) accepted: [...] torvalds#483/p calls: stack overflow using two frames (post-call access) FAIL Unexpected success to load! 0: (85) call pc+2 caller: R10=fp0,call_-1 callee: frame1: R1=ctx(id=0,off=0,imm=0) R10=fp0,call_0 3: (72) *(u8 *)(r10 -300) = 0 4: (b7) r0 = 0 5: (95) exit returning from callee: frame1: R0_w=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0,call_0 to caller at 1: R0_w=inv0 R10=fp0,call_-1 from 5 to 1: R0=inv0 R10=fp0,call_-1 1: (72) *(u8 *)(r10 -300) = 0 2: (95) exit processed 6 insns, stack depth 300+300 [...] Summary: 704 PASSED, 1 FAILED AFAICS the JIT-generated code for the second testcase shows that this really causes the stack pointer to be decremented by 300+300: first function: 00000000 55 push rbp 00000001 4889E5 mov rbp,rsp 00000004 4881EC58010000 sub rsp,0x158 0000000B 4883ED28 sub rbp,byte +0x28 [...] 00000025 E89AB3AFE5 call 0xffffffffe5afb3c4 0000002A C685D4FEFFFF00 mov byte [rbp-0x12c],0x0 [...] 00000041 4883C528 add rbp,byte +0x28 00000045 C9 leave 00000046 C3 ret second function: 00000000 55 push rbp 00000001 4889E5 mov rbp,rsp 00000004 4881EC58010000 sub rsp,0x158 0000000B 4883ED28 sub rbp,byte +0x28 [...] 00000025 C685D4FEFFFF00 mov byte [rbp-0x12c],0x0 [...] 0000003E 4883C528 add rbp,byte +0x28 00000042 C9 leave 00000043 C3 ret Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

aviwad · 2018-03-14T03:56:33Z

lol

There are a number of CamelCase variables remaining in the source files of modules rtl_pci, rtl_usb, and rtlwifi. The following checkpatch excettions are also fixed: for_kalle1/0001-rtlwifi-Remove-CamelCase-variables-from-base-code.patch ----------------------------------------------------------------------- CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]' torvalds#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1]' torvalds#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { WARNING: line over 80 characters #70: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:379: + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != CHECK: No space is necessary after a cast torvalds#186: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:396: + status->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#208: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c:335: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#243: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:301: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#252: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:368: + stats.rx_is40mhzpacket = (bool) GET_RX_DESC_BW(rxdesc); CHECK: No space is necessary after a cast torvalds#265: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c:475: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); WARNING: Unnecessary space before function pointer arguments torvalds#455: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:1462: + void (*writen_sync) (struct rtl_priv *rtlpriv, u32 addr, void *buf, WARNING: Unnecessary space before function pointer arguments torvalds#483: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:2257: + void (*fill_fake_txdesc) (struct ieee80211_hw *hw, u8 *pdesc, Note that not all checkpatch exceptions are addressed. Those will be handled in later patches. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

There are a number of CamelCase variables remaining in the source files of modules rtl_pci, rtl_usb, and rtlwifi. The following checkpatch excettions are also fixed: for_kalle1/0001-rtlwifi-Remove-CamelCase-variables-from-base-code.patch ----------------------------------------------------------------------- CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]' torvalds#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1]' torvalds#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { WARNING: line over 80 characters #70: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:379: + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != CHECK: No space is necessary after a cast torvalds#186: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:396: + status->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#208: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c:335: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#243: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:301: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast torvalds#252: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:368: + stats.rx_is40mhzpacket = (bool) GET_RX_DESC_BW(rxdesc); CHECK: No space is necessary after a cast torvalds#265: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c:475: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); WARNING: Unnecessary space before function pointer arguments torvalds#455: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:1462: + void (*writen_sync) (struct rtl_priv *rtlpriv, u32 addr, void *buf, WARNING: Unnecessary space before function pointer arguments torvalds#483: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:2257: + void (*fill_fake_txdesc) (struct ieee80211_hw *hw, u8 *pdesc, Note that not all checkpatch exceptions are addressed. Those will be handled in later patches. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>

Typedef is not recommended in the Linux kernel.The klocwork static code analyzer takes the enumeration as the full range of intel_gvt_gtt_type_t. But the intel_gvt_gtt_type_t will never be used in full range. For example, the GTT_TYPE_INVALID will never be used as an index of an array. Remove the typedef and let the enumeration starts from zero to pass klocwork analysis. This patch fixed the critial issues torvalds#483, torvalds#551, torvalds#665 reported by klockwork. v3: - Remove the typedef and let the enumeration starts from zero. Signed-off-by: Aleksei Gimbitskii <aleksei.gimbitskii@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> CC: Colin Xu <colin.xu@intel.com> Reviewed-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Here, I will use the term Proximity Domains for the ACPI description and Numa Nodes for the in kernel representation. Until ACPI 6.3 it was arguably possible to interpret the specification as allowing _PXM in DSDT and similar to define additional Proximity Domains. The reality was that was never the intent, and a 'clarification' was added in ACPI 6.3 [1]. In practice I think the kernel has never allowed any other interpretaion, except possibly on adhoc base within some out of tree driver (using it very very carefully given potential to crash when using various standard calls such as devm_kzalloc). Proximity Domains are always defined in SRAT. In ACPI, there are methods defined in ACPI to allow their characteristics to be tweaked later but Proximity Domains have to be referenced in this table at boot, thus allowing Linux to instantiate relevant Numa Node data structures. We ran into a problem when enabling _PXM handling for PCI devices and found there were boards out there advertising devices in proximity domains that didn't exist [2]. The fix suggested here is to modfiy the function acpi_map_pxm_to_node. This function is both used to create and lookup proximity domains. A parameter is added to specify whether it should create a new proximity domain when it encounters a Proximity Domain ID that it hasn't seen before. Naturally there is a quirk. For SRAT ITS entries on ARM64 the handling is done with an additional pass of SRAT, potentially later in the boot. We could modify that behaviour so we could identify the existence of Proximity Domains unique to the ITS structures, and handle them as a special case of a Genric Initiator (once support for those merges) however... Currently (5.8-rc2) setting the Proximity Domain of an ITS to one that hasn't been instantiated by being specified in another type of SRAT resource entry results in: ITS [mem 0x202100000-0x20211ffff] ITS@0x0000000202100000: Using ITS number 0 Unable to handle kernel paging request at virtual address 0000000000001a08 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [0000000000001a08] user address but active_mm is swapper Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G A 5.8.0-rc2 torvalds#483 pstate: 80000089 (Nzcv daIf -PAN -UAO BTYPE=--) pc : __alloc_pages_nodemask+0xe8/0x338 lr : __alloc_pages_nodemask+0xc0/0x338 sp : ffffa81540c139b0 x29: ffffa81540c139b0 x28: 0000000000000001 x27: 0000000000000100 x26: ffffa81540c1ad38 x25: 0000000000000000 x24: 0000000000000000 x23: ffffa81540c23c00 x22: 0000000000000004 x21: 0000000000000002 x20: 0000000000001a00 x19: 0000000000000100 x18: 0000000000000010 x17: 000000000001f000 x16: 000000000000007f x15: ffffa81540c24070 x14: ffffffffffffffff x13: ffffa815c0c137d7 x12: ffffa81540c137e4 x11: ffffa81540c3e000 x10: ffffa81540ecee68 x9 : ffffa8153f0f61d8 x8 : ffffa81540ecf000 x7 : 0000000000000141 x6 : ffffa81540ecf401 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000081 x0 : 0000000000001a00 Call trace: __alloc_pages_nodemask+0xe8/0x338 alloc_pages_node.constprop.0+0x34/0x40 its_probe_one+0x2f8/0xb18 gic_acpi_parse_madt_its+0x108/0x150 acpi_table_parse_entries_array+0x17c/0x264 acpi_table_parse_entries+0x48/0x6c acpi_table_parse_madt+0x30/0x3c its_init+0x1c4/0x644 gic_init_bases+0x4b8/0x4ec gic_acpi_init+0x134/0x264 acpi_match_madt+0x4c/0x84 acpi_table_parse_entries_array+0x17c/0x264 acpi_table_parse_entries+0x48/0x6c acpi_table_parse_madt+0x30/0x3c __acpi_probe_device_table+0x8c/0xe8 irqchip_init+0x3c/0x48 init_IRQ+0xcc/0x100 start_kernel+0x33c/0x548 As we die in this case in existing kernels, we can be fairly sure that no one actually has such a firmware in production. As such this patch avoids the complexity that would be needed to handle this corner case, and simply does not allow the ITS entry parsing code to instantiate new Numa Nodes. If one is encountered that does not already exist, then NO_NUMA_NODE is assigned and a warning printed just as if the value had been greater than allowed Numa Nodes. "SRAT: Invalid NUMA node -1 in ITS affinity" I have only tested this for now on our ARM64 Kunpeng920 servers. Open questions: * should we warn about a broken firmware or insufficent value of NUMA_NODES_SHIFT if we find a firmware trying to assign any device to a non existent Proximity Domain. * previously an smmuv3 in IORT with a Proximity Domain set to a non existent value would have resulted in a failure to add the device. After this change it will be added to the default node. Is that a problem? [1] Note in ACPI Specification 6.3 5.2.16 System Resource Affinity Table (SRAT) [2] https://patchwork.kernel.org/patch/10597777/ Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Here, I will use the term Proximity Domains for the ACPI description and Numa Nodes for the in kernel representation. Until ACPI 6.3 it was arguably possible to interpret the specification as allowing _PXM in DSDT and similar to define additional Proximity Domains. The reality was that was never the intent, and a 'clarification' was added in ACPI 6.3 [1]. In practice I think the kernel has never allowed any other interpretaion, except possibly on adhoc base within some out of tree driver (using it very very carefully given potential to crash when using various standard calls such as devm_kzalloc). Proximity Domains are always defined in SRAT. In ACPI, there are methods defined in ACPI to allow their characteristics to be tweaked later but Proximity Domains have to be referenced in this table at boot, thus allowing Linux to instantiate relevant Numa Node data structures. We ran into a problem when enabling _PXM handling for PCI devices and found there were boards out there advertising devices in proximity domains that didn't exist [2]. The fix suggested here is to modfiy the function acpi_map_pxm_to_node. This function is both used to create and lookup proximity domains. A parameter is added to specify whether it should create a new proximity domain when it encounters a Proximity Domain ID that it hasn't seen before. Naturally there is a quirk. For SRAT ITS entries on ARM64 the handling is done with an additional pass of SRAT, potentially later in the boot. We could modify that behaviour so we could identify the existence of Proximity Domains unique to the ITS structures, and handle them as a special case of a Genric Initiator (once support for those merges) however... Currently (5.8-rc2) setting the Proximity Domain of an ITS to one that hasn't been instantiated by being specified in another type of SRAT resource entry results in: ITS [mem 0x202100000-0x20211ffff] ITS@0x0000000202100000: Using ITS number 0 Unable to handle kernel paging request at virtual address 0000000000001a08 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [0000000000001a08] user address but active_mm is swapper Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G A 5.8.0-rc2 torvalds#483 pstate: 80000089 (Nzcv daIf -PAN -UAO BTYPE=--) pc : __alloc_pages_nodemask+0xe8/0x338 lr : __alloc_pages_nodemask+0xc0/0x338 sp : ffffa81540c139b0 x29: ffffa81540c139b0 x28: 0000000000000001 x27: 0000000000000100 x26: ffffa81540c1ad38 x25: 0000000000000000 x24: 0000000000000000 x23: ffffa81540c23c00 x22: 0000000000000004 x21: 0000000000000002 x20: 0000000000001a00 x19: 0000000000000100 x18: 0000000000000010 x17: 000000000001f000 x16: 000000000000007f x15: ffffa81540c24070 x14: ffffffffffffffff x13: ffffa815c0c137d7 x12: ffffa81540c137e4 x11: ffffa81540c3e000 x10: ffffa81540ecee68 x9 : ffffa8153f0f61d8 x8 : ffffa81540ecf000 x7 : 0000000000000141 x6 : ffffa81540ecf401 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000081 x0 : 0000000000001a00 Call trace: __alloc_pages_nodemask+0xe8/0x338 alloc_pages_node.constprop.0+0x34/0x40 its_probe_one+0x2f8/0xb18 gic_acpi_parse_madt_its+0x108/0x150 acpi_table_parse_entries_array+0x17c/0x264 acpi_table_parse_entries+0x48/0x6c acpi_table_parse_madt+0x30/0x3c its_init+0x1c4/0x644 gic_init_bases+0x4b8/0x4ec gic_acpi_init+0x134/0x264 acpi_match_madt+0x4c/0x84 acpi_table_parse_entries_array+0x17c/0x264 acpi_table_parse_entries+0x48/0x6c acpi_table_parse_madt+0x30/0x3c __acpi_probe_device_table+0x8c/0xe8 irqchip_init+0x3c/0x48 init_IRQ+0xcc/0x100 start_kernel+0x33c/0x548 As we die in this case in existing kernels, we can be fairly sure that no one actually has such a firmware in production. As such this patch avoids the complexity that would be needed to handle this corner case, and simply does not allow the ITS entry parsing code to instantiate new Numa Nodes. If one is encountered that does not already exist, then NO_NUMA_NODE is assigned and a warning printed just as if the value had been greater than allowed Numa Nodes. "SRAT: Invalid NUMA node -1 in ITS affinity" I have only tested this for now on our ARM64 Kunpeng920 servers and a range of qemu x86 and arm64 configurations. Note minor merge issue with Dan William's series [3]. Merge fixes should be straight forward. [1] Note in ACPI Specification 6.3 5.2.16 System Resource Affinity Table (SRAT) [2] https://patchwork.kernel.org/patch/10597777/ [3] https://lore.kernel.org/patchwork/cover/1271398/ Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Add `dbg!` macro from `std`

Merge pull request #1 from torvalds/master

b577ca7

Update upstream

boldtrn mentioned this pull request Nov 2, 2017

Contributing via signed commits graphhopper/graphhopper#1208

Closed

ojeda added a commit to ojeda/linux that referenced this pull request Oct 5, 2021

Merge pull request torvalds#483 from niklasmohrin/dbg-macro

0d6f2a0

Add `dbg!` macro from `std`

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge pull request #1 from torvalds/master #483

Merge pull request #1 from torvalds/master #483

cyberaddicted commented Oct 28, 2017

KernelPRBot commented Oct 28, 2017

aviwad commented Mar 14, 2018

Merge pull request #1 from torvalds/master #483

Are you sure you want to change the base?

Merge pull request #1 from torvalds/master #483

Conversation

cyberaddicted commented Oct 28, 2017

KernelPRBot commented Oct 28, 2017

How do I format my contribution?

Who do I send my contribution to?

How do I send my contribution?

How do I get help if I'm stuck?

I sent my patch - now what?

Further information

aviwad commented Mar 14, 2018