June 2018 - Linux-stable-mirror

[net 1/5] ixgbe: Fix setting of TC configuration for macvlan case

by Jeff Kirsher

From: Alexander Duyck <alexander.h.duyck(a)intel.com> When we were enabling macvlan interfaces we weren't correctly configuring things until ixgbe_setup_tc was called a second time either by tweaking the number of queues or increasing the macvlan count past 15. The issue came down to the fact that num_rx_pools is not populated until after the queues and interrupts are reinitialized. Instead of trying to set it sooner we can just move the call to setup at least 1 traffic class to the SR-IOV/VMDq setup function so that we just set it for this one case. We already had a spot that was configuring the queues for TC 0 in the code here anyway so it makes sense to also set the number of TCs here as well. CC: stable <stable(a)vger.kernel.org> Fixes: 49cfbeb7a95c ("ixgbe: Fix handling of macvlan Tx offload") Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> --- drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 8 ++++++++ drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 -------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c index 893a9206e718..d361f570ca37 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c @@ -593,6 +593,14 @@ static bool ixgbe_set_sriov_queues(struct ixgbe_adapter *adapter) } #endif + /* To support macvlan offload we have to use num_tc to + * restrict the queues that can be used by the device. + * By doing this we can avoid reporting a false number of + * queues. + */ + if (vmdq_i > 1) + netdev_set_num_tc(adapter->netdev, 1); + /* populate TC0 for use by pool 0 */ netdev_set_tc_queue(adapter->netdev, 0, adapter->num_rx_queues_per_pool, 0); diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index 4929f7265598..f9e0dc041cfb 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -8822,14 +8822,6 @@ int ixgbe_setup_tc(struct net_device *dev, u8 tc) } else { netdev_reset_tc(dev); - /* To support macvlan offload we have to use num_tc to - * restrict the queues that can be used by the device. - * By doing this we can avoid reporting a false number of - * queues. - */ - if (!tc && adapter->num_rx_pools > 1) - netdev_set_num_tc(dev, 1); - if (adapter->hw.mac.type == ixgbe_mac_82598EB) adapter->hw.fc.requested_mode = adapter->last_lfc_mode; -- 2.17.1

7 years

1
0
0 0

Re: [PATCH 4.16 01/48] mmap: introduce sane default mmap limits

by Greg Kroah-Hartman

On Mon, Jun 11, 2018 at 08:12:45AM +1000, David Airlie wrote: > Can you make sure you pull in > > 76ef6b28ea4f81c3d511866a9b31392caa833126 (tag: > drm-fixes-for-v4.17-rc6-urgent) > Author: Dave Airlie <airlied(a)redhat.com> > Date: Tue May 15 13:38:15 2018 +1000 > > drm: set FMODE_UNSIGNED_OFFSET for drm files > > Into anywhere this first patch goes? Thanks for pointing this out, now queued up. greg k-h

7 years

1
0
0 0

[PATCH] mm: Fix devmem_is_allowed() for sub-page System RAM intersections

by Dan Williams

Hussam reports: I was poking around and for no real reason, I did cat /dev/mem and strings /dev/mem. Then I saw the following warning in dmesg. I saved it and rebooted immediately. memremap attempted on mixed range 0x000000000009c000 size: 0x1000 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11810 at kernel/memremap.c:98 memremap+0x104/0x170 [..] Call Trace: xlate_dev_mem_ptr+0x25/0x40 read_mem+0x89/0x1a0 __vfs_read+0x36/0x170 The memremap() implementation checks for attempts to remap System RAM with MEMREMAP_WB and instead redirects those mapping attempts to the linear map. However, that only works if the physical address range being remapped is page aligned. In low memory we have situations like the following: 00000000-00000fff : Reserved 00001000-0009fbff : System RAM 0009fc00-0009ffff : Reserved ...where System RAM intersects Reserved ranges on a sub-page page granularity. Given that devmem_is_allowed() special cases any attempt to map System RAM in the first 1MB of memory, replace page_is_ram() with the more precise region_intersects() to trap attempts to map disallowed ranges. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199999 Fixes: 92281dee825f ("arch: introduce memremap()") Cc: <stable(a)vger.kernel.org> Cc: Christoph Hellwig <hch(a)lst.de> Reported-by: Hussam Al-Tayeb <me(a)hussam.eu.org> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- arch/x86/mm/init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index fec82b577c18..cee58a972cb2 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -706,7 +706,9 @@ void __init init_mem_mapping(void) */ int devmem_is_allowed(unsigned long pagenr) { - if (page_is_ram(pagenr)) { + if (region_intersects(PFN_PHYS(pagenr), PAGE_SIZE, + IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE) + != REGION_DISJOINT) { /* * For disallowed memory regions in the low 1MB range, * request that the page be shown as all zeros.

7 years

1
0
0 0

Please apply this commit to v4.14.y, 4.16.y and 4.17.y: c3635da2a336 ("PCI: hv: Do not wait forever on a device that has disappeared")

by Dexuan Cui

Hi, The patch has been in the mainline, and I have verified the commit can be cherry-picked cleanly to these 3 stable branches. The issue fixed by the patch also exists in 4.14, 4.16 and 4.17. It looks I forgot to add a "Cc: stable(a)vger.kernel.org" tag. Sorry. Thanks, -- Dexuan

7 years

2
1
0 0

[PATCH v3 1/4] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ

by Amit Pundir

From: Suren Baghdasaryan <surenb(a)google.com> Out of bounds kernel accesses in st21nfca's NFC HCI layer might happen when handling ATR_REQ events if user-specified atr_req->length is bigger than the buffer size. In that case memcpy() inside st21nfca_tm_send_atr_res() will read extra bytes resulting in OOB read from the kernel heap. cc: Stable <stable(a)vger.kernel.org> Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- v3..v1: Resend. No changes. drivers/nfc/st21nfca/dep.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c index fd08be2917e6..3420c5104c94 100644 --- a/drivers/nfc/st21nfca/dep.c +++ b/drivers/nfc/st21nfca/dep.c @@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev *hdev, atr_req = (struct st21nfca_atr_req *)skb->data; - if (atr_req->length < sizeof(struct st21nfca_atr_req)) { + if (atr_req->length < sizeof(struct st21nfca_atr_req) || + atr_req->length > skb->len) { r = -EPROTO; goto exit; } -- 2.7.4

7 years

2
3
0 0

Re: [PATCH] xfs: fix incorrect log_flushed on fsync

by Amir Goldstein

On Tue, Sep 19, 2017 at 9:32 AM, Greg KH <greg(a)kroah.com> wrote: > On Mon, Sep 18, 2017 at 10:29:25PM +0300, Amir Goldstein wrote: >> On Mon, Sep 18, 2017 at 9:35 PM, Greg KH <greg(a)kroah.com> wrote: >> > On Mon, Sep 18, 2017 at 09:00:30PM +0300, Amir Goldstein wrote: >> >> On Mon, Sep 18, 2017 at 8:11 PM, Darrick J. Wong >> >> <darrick.wong(a)oracle.com> wrote: >> >> > On Fri, Sep 15, 2017 at 03:40:24PM +0300, Amir Goldstein wrote: >> >> >> On Wed, Aug 30, 2017 at 4:38 PM, Amir Goldstein <amir73il(a)gmail.com> wrote: >> >> >> > When calling into _xfs_log_force{,_lsn}() with a pointer >> >> >> > to log_flushed variable, log_flushed will be set to 1 if: >> >> >> > 1. xlog_sync() is called to flush the active log buffer >> >> >> > AND/OR >> >> >> > 2. xlog_wait() is called to wait on a syncing log buffers >> >> >> > >> >> >> > xfs_file_fsync() checks the value of log_flushed after >> >> >> > _xfs_log_force_lsn() call to optimize away an explicit >> >> >> > PREFLUSH request to the data block device after writing >> >> >> > out all the file's pages to disk. >> >> >> > >> >> >> > This optimization is incorrect in the following sequence of events: >> >> >> > >> >> >> > Task A Task B >> >> >> > ------------------------------------------------------- >> >> >> > xfs_file_fsync() >> >> >> > _xfs_log_force_lsn() >> >> >> > xlog_sync() >> >> >> > [submit PREFLUSH] >> >> >> > xfs_file_fsync() >> >> >> > file_write_and_wait_range() >> >> >> > [submit WRITE X] >> >> >> > [endio WRITE X] >> >> >> > _xfs_log_force_lsn() >> >> >> > xlog_wait() >> >> >> > [endio PREFLUSH] >> >> >> > >> >> >> > The write X is not guarantied to be on persistent storage >> >> >> > when PREFLUSH request in completed, because write A was submitted >> >> >> > after the PREFLUSH request, but xfs_file_fsync() of task A will >> >> >> > be notified of log_flushed=1 and will skip explicit flush. >> >> >> > >> >> >> > If the system crashes after fsync of task A, write X may not be >> >> >> > present on disk after reboot. >> >> >> > >> >> >> > This bug was discovered and demonstrated using Josef Bacik's >> >> >> > dm-log-writes target, which can be used to record block io operations >> >> >> > and then replay a subset of these operations onto the target device. >> >> >> > The test goes something like this: >> >> >> > - Use fsx to execute ops of a file and record ops on log device >> >> >> > - Every now and then fsync the file, store md5 of file and mark >> >> >> > the location in the log >> >> >> > - Then replay log onto device for each mark, mount fs and compare >> >> >> > md5 of file to stored value >> >> >> > >> >> >> > Cc: Christoph Hellwig <hch(a)lst.de> >> >> >> > Cc: Josef Bacik <jbacik(a)fb.com> >> >> >> > Cc: <stable(a)vger.kernel.org> >> >> >> > Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> >> >> >> > --- >> >> >> > >> >> >> > Christoph, Dave, >> >> >> > >> >> >> > It's hard to believe, but I think the reported bug has been around >> >> >> > since 2005 f538d4da8d52 ("[XFS] write barrier support"), but I did >> >> >> > not try to test old kernels. >> >> >> >> >> >> Forgot to tag commit message with: >> >> >> Fixes: f538d4da8d52 ("[XFS] write barrier support") >> >> >> >> >> >> Maybe the tag could be added when applying to recent stables, >> >> >> so distros and older downstream stables can see the tag. >> >> >> >> >> >> The disclosure of the security bug fix (commit b31ff3cdf5) made me wonder >> >> >> if possible data loss bug should also be disclosed in some distros forum? >> >> >> I bet some users would care more about the latter than the former. >> >> >> Coincidentally, both data loss and security bugs fix the same commit.. >> >> > >> >> > Yes the the patch ought to get sent on to stable w/ fixes tag. One >> >> > would hope that the distros will pick up the stable fixes from there. >> >> >> >> >> >> Greg, for your consideration, please add >> >> Fixes: f538d4da8d52 ("[XFS] write barrier support") >> >> If not pushed yet. >> > >> > Add it to what? >> >> Sorry, add that tag when applying commit 47c7d0b1950258312 >> to stable trees, since I missed adding the tag before it was merged >> to master. > > Nah, as the tag is just needed to let me know where to backport stuff > to, I don't think it matters when I add it to the stable tree itself, so > I'll leave it as-is. > Greg, Related or not to above Fixes discussion, I now noticed that you never picked the patch for kernel 4.4. Ben did take it to 3.2 and 3.16 BTW. This is a very critical bug fix IMO. Were you waiting for an ACK from xfs maintainers or just an oversight? Or was it me who had to check up on that? Thanks, Amir.

7 years

2
1
0 0

Linux 4.9.107 is not available on www.kernel.org

by Pavlos Parissis

Hi, Linux 4.9.107 was released on Jun 7th and www.kernel.org still points to 4.9.106 as latest version for 4.9 tree. I have seen delays before, but not for more than an hour. Is something broken? Cheers, Pavlos

7 years

2
2
0 0

[merged] fs-binfmt_miscc-do-not-allow-offset-overflow.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: fs/binfmt_misc.c: do not allow offset overflow has been removed from the -mm tree. Its filename was fs-binfmt_miscc-do-not-allow-offset-overflow.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> Subject: fs/binfmt_misc.c: do not allow offset overflow WHen registering a new binfmt_misc handler, it is possible to overflow the offset to get a negative value, which might crash the system, or possibly leak kernel data. Here is a crash log when 2500000000 was used as an offset: [ 6050.251552] BUG: unable to handle kernel paging request at ffff989cfd6edca0 [ 6050.252053] IP: load_misc_binary+0x22b/0x470 [binfmt_misc] [ 6050.252053] PGD 1ef3e067 P4D 1ef3e067 PUD 0 [ 6050.252053] Oops: 0000 [#1] SMP NOPTI [ 6050.252053] Modules linked in: binfmt_misc kvm_intel ppdev kvm irqbypass joydev input_leds serio_raw mac_hid parport_pc qemu_fw_cfg parpy [ 6050.252053] CPU: 0 PID: 2499 Comm: bash Not tainted 4.15.0-22-generic #24-Ubuntu [ 6050.252053] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014 [ 6050.252053] RIP: 0010:load_misc_binary+0x22b/0x470 [binfmt_misc] [ 6050.252053] RSP: 0018:ffffb6e383017e18 EFLAGS: 00010202 [ 6050.252053] RAX: 0000000000000003 RBX: ffff989d74a47100 RCX: ffff989cfd6edca0 [ 6050.252053] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff989d7d2e95e5 [ 6050.252053] RBP: ffffb6e383017e48 R08: 0000000000000001 R09: 0000000000000000 [ 6050.252053] R10: 0000000000000000 R11: fefefefefefefeff R12: 0000000000000001 [ 6050.252053] R13: ffff989d7d2e9580 R14: 0000000000000000 R15: ffffffffc0592160 [ 6050.252053] FS: 00007fa424c89740(0000) GS:ffff989d7fc00000(0000) knlGS:0000000000000000 [ 6050.252053] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6050.252053] CR2: ffff989cfd6edca0 CR3: 000000003db08000 CR4: 00000000000006f0 [ 6050.252053] Call Trace: [ 6050.252053] search_binary_handler+0x97/0x1d0 [ 6050.252053] do_execveat_common.isra.34+0x667/0x810 [ 6050.252053] SyS_execve+0x31/0x40 [ 6050.252053] do_syscall_64+0x73/0x130 [ 6050.252053] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Use kstrtoint instead of simple_strtoul. It will work as the code already set the delimiter byte to '\0' and we only do it when the field is not empty. Tested with offsets -1, 2500000000, UINT_MAX and INT_MAX. Also tested with examples documented at Documentation/admin-guide/binfmt-misc.rst and other registrations from packages on Ubuntu. Link: http://lkml.kernel.org/r/20180529135648.14254-1-cascardo@canonical.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/binfmt_misc.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff -puN fs/binfmt_misc.c~fs-binfmt_miscc-do-not-allow-offset-overflow fs/binfmt_misc.c --- a/fs/binfmt_misc.c~fs-binfmt_miscc-do-not-allow-offset-overflow +++ a/fs/binfmt_misc.c @@ -387,8 +387,13 @@ static Node *create_entry(const char __u s = strchr(p, del); if (!s) goto einval; - *s++ = '\0'; - e->offset = simple_strtoul(p, &p, 10); + *s = '\0'; + if (p != s) { + int r = kstrtoint(p, 10, &e->offset); + if (r != 0 || e->offset < 0) + goto einval; + } + p = s; if (*p++) goto einval; pr_debug("register: offset: %#x\n", e->offset); @@ -428,7 +433,8 @@ static Node *create_entry(const char __u if (e->mask && string_unescape_inplace(e->mask, UNESCAPE_HEX) != e->size) goto einval; - if (e->size + e->offset > BINPRM_BUF_SIZE) + if (e->size > BINPRM_BUF_SIZE || + BINPRM_BUF_SIZE - e->size < e->offset) goto einval; pr_debug("register: magic/mask length: %i\n", e->size); if (USE_DEBUG) { _ Patches currently in -mm which might be from cascardo(a)canonical.com are

7 years

1
0
0 0

[merged] mm-page_alloc-do-not-break-__gfp_thisnode-by-zonelist-reset.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, page_alloc: do not break __GFP_THISNODE by zonelist reset has been removed from the -mm tree. Its filename was mm-page_alloc-do-not-break-__gfp_thisnode-by-zonelist-reset.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Vlastimil Babka <vbabka(a)suse.cz> Subject: mm, page_alloc: do not break __GFP_THISNODE by zonelist reset In __alloc_pages_slowpath() we reset zonelist and preferred_zoneref for allocations that can ignore memory policies. The zonelist is obtained from current CPU's node. This is a problem for __GFP_THISNODE allocations that want to allocate on a different node, e.g. because the allocating thread has been migrated to a different CPU. This has been observed to break SLAB in our 4.4-based kernel, because there it relies on __GFP_THISNODE working as intended. If a slab page is put on wrong node's list, then further list manipulations may corrupt the list because page_to_nid() is used to determine which node's list_lock should be locked and thus we may take a wrong lock and race. Current SLAB implementation seems to be immune by luck thanks to commit 511e3a058812 ("mm/slab: make cache_grow() handle the page allocated on arbitrary node") but there may be others assuming that __GFP_THISNODE works as promised. We can fix it by simply removing the zonelist reset completely. There is actually no reason to reset it, because memory policies and cpusets don't affect the zonelist choice in the first place. This was different when commit 183f6371aac2 ("mm: ignore mempolicies when using ALLOC_NO_WATERMARK") introduced the code, as mempolicies provided their own restricted zonelists. We might consider this for 4.17 although I don't know if there's anything currently broken. SLAB is currently not affected, but in kernels older than 4.7 that don't yet have 511e3a058812 ("mm/slab: make cache_grow() handle the page allocated on arbitrary node") it is. That's at least 4.4 LTS. Older ones I'll have to check. So stable backports should be more important, but will have to be reviewed carefully, as the code went through many changes. BTW I think that also the ac->preferred_zoneref reset is currently useless if we don't also reset ac->nodemask from a mempolicy to NULL first (which we probably should for the OOM victims etc?), but I would leave that for a separate patch. Link: http://lkml.kernel.org/r/20180525130853.13915-1-vbabka@suse.cz Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Fixes: 183f6371aac2 ("mm: ignore mempolicies when using ALLOC_NO_WATERMARK") Acked-by: Mel Gorman <mgorman(a)techsingularity.net> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: David Rientjes <rientjes(a)google.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 1 - 1 file changed, 1 deletion(-) diff -puN mm/page_alloc.c~mm-page_alloc-do-not-break-__gfp_thisnode-by-zonelist-reset mm/page_alloc.c --- a/mm/page_alloc.c~mm-page_alloc-do-not-break-__gfp_thisnode-by-zonelist-reset +++ a/mm/page_alloc.c @@ -4169,7 +4169,6 @@ retry: * orientated. */ if (!(alloc_flags & ALLOC_CPUSET) || reserve_flags) { - ac->zonelist = node_zonelist(numa_node_id(), gfp_mask); ac->preferred_zoneref = first_zones_zonelist(ac->zonelist, ac->high_zoneidx, ac->nodemask); } _ Patches currently in -mm which might be from vbabka(a)suse.cz are

7 years

1
0
0 0

[PATCH] arm64: Fix syscall restarting around signal suppressed by tracer

by Dave Martin

Commit 17c2895 ("arm64: Abstract syscallno manipulation") abstracts out the pt_regs.syscallno value for a syscall cancelled by a tracer as NO_SYSCALL, and provides helpers to set and check for this condition. However, the way this was implemented has the unintended side-effect of disabling part of the syscall restart logic. This comes about because the second in_syscall() check in do_signal() re-evaluates the "in a syscall" condition based on the updated pt_regs instead of the original pt_regs. forget_syscall() is explicitly called prior to the second check in order to prevent restart logic in the ret_to_user path being spuriously triggered, which means that the second in_syscall() check always yields false. This triggers a failure in tools/testing/selftests/seccomp/seccomp_bpf.c, when using ptrace to suppress a signal that interrups a nanosleep() syscall. Misbehaviour of this type is only expected in the case where a tracer suppresses a signal and the target process is either being single-stepped or the interrupted syscall attempts to restart via -ERESTARTBLOCK. This patch restores the old behaviour by performing the in_syscall() check only once at the start of the function. Fixes: 17c289586009 ("arm64: Abstract syscallno manipulation") Signed-off-by: Dave Martin <Dave.Martin(a)arm.com> Reported-by: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: <stable(a)vger.kernel.org> # 4.14.x- --- arch/arm64/kernel/signal.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 154b7d3..f212090 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -830,11 +830,12 @@ static void do_signal(struct pt_regs *regs) unsigned long continue_addr = 0, restart_addr = 0; int retval = 0; struct ksignal ksig; + bool syscall = in_syscall(regs); /* * If we were from a system call, check for system call restarting... */ - if (in_syscall(regs)) { + if (syscall) { continue_addr = regs->pc; restart_addr = continue_addr - (compat_thumb_mode(regs) ? 2 : 4); retval = regs->regs[0]; @@ -886,7 +887,7 @@ static void do_signal(struct pt_regs *regs) * Handle restarting a different system call. As above, if a debugger * has chosen to restart at a different PC, ignore the restart. */ - if (in_syscall(regs) && regs->pc == restart_addr) { + if (syscall && regs->pc == restart_addr) { if (retval == -ERESTART_RESTARTBLOCK) setup_restart_syscall(regs); user_rewind_single_step(current); -- 2.1.4

7 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2018