- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] [PATCH] scsi: libfc: fix ELS request handling

by Martin Wilck

The modification of fc_lport_recv_els_req() in commit fcabb09e59a7 (merged in 4.12-rc1) caused certain requests not to be handled at all. Fix that. Fixes: fcabb09e59a7 "scsi: libfc: directly call ELS request handlers" Signed-off-by: Martin Wilck <mwilck(a)suse.com> --- drivers/scsi/libfc/fc_lport.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/libfc/fc_lport.c b/drivers/scsi/libfc/fc_lport.c index 2fd0ec651170..787e82435241 100644 --- a/drivers/scsi/libfc/fc_lport.c +++ b/drivers/scsi/libfc/fc_lport.c @@ -904,10 +904,14 @@ static void fc_lport_recv_els_req(struct fc_lport *lport, case ELS_FLOGI: if (!lport->point_to_multipoint) fc_lport_recv_flogi_req(lport, fp); + else + fc_rport_recv_req(lport, fp); break; case ELS_LOGO: if (fc_frame_sid(fp) == FC_FID_FLOGI) fc_lport_recv_logo_req(lport, fp); + else + fc_rport_recv_req(lport, fp); break; case ELS_RSCN: lport->tt.disc_recv_req(lport, fp); -- 2.15.0

6 years, 6 months

3
2
0 0

[Linux-stable-mirror] + mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/cma: fix alloc_contig_range ret code/potential leak has been added to the -mm tree. Its filename is mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-cma-fix-alloc_contig_range-ret-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-cma-fix-alloc_contig_range-ret-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: mm/cma: fix alloc_contig_range ret code/potential leak If the call __alloc_contig_migrate_range() in alloc_contig_range returns -EBUSY, processing continues so that test_pages_isolated() is called where there is a tracepoint to identify the busy pages. However, it is possible for busy pages to become available between the calls to these two routines. In this case, the range of pages may be allocated. Unfortunately, the original return code (ret == -EBUSY) is still set and returned to the caller. Therefore, the caller believes the pages were not allocated and they are leaked. Update comment to indicate that allocation is still possible even if __alloc_contig_migrate_range returns -EBUSY. Also, clear return code in this case so that it is not accidentally used or returned to caller. Link: http://lkml.kernel.org/r/20171122185214.25285-1-mike.kravetz@oracle.com Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Nazarewicz <mina86(a)mina86.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff -puN mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2 mm/page_alloc.c --- a/mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2 +++ a/mm/page_alloc.c @@ -7652,11 +7652,18 @@ int alloc_contig_range(unsigned long sta /* * In case of -EBUSY, we'd like to know which page causes problem. - * So, just fall through. We will check it in test_pages_isolated(). + * So, just fall through. test_pages_isolated() has a tracepoint + * which will report the busy page. + * + * It is possible that busy pages could become available before + * the call to test_pages_isolated, and the range will actually be + * allocated. So, if we fall through be sure to clear ret so that + * -EBUSY is not accidentally used or returned to caller. */ ret = __alloc_contig_migrate_range(&cc, start, end); if (ret && ret != -EBUSY) goto done; + ret =0; /* * Pages from [start, end) are within a MAX_ORDER_NR_PAGES _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] [to-be-updated] mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/cma: fix alloc_contig_range ret code/potential leak has been removed from the -mm tree. Its filename was mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch This patch was dropped because an updated version will be merged ------------------------------------------------------ From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: mm/cma: fix alloc_contig_range ret code/potential leak In an attempt to make contiguous allocation routines more available to drivers, I have been experimenting with code similar to that used by alloc_gigantic_page(). While stressing this code with many other allocations and frees in progress, I would sometimes notice large 'leaks' of page ranges. I traced this down to the routine alloc_contig_range() itself. In 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure") the code was changed so that an -EBUSY returned by __alloc_contig_migrate_range() would not immediately return to the caller. Rather, processing continues so that test_pages_isolated() is eventually called. This is done because test_pages_isolated() has a tracepoint to identify the busy pages. However, it is possible (observed in my testing) that pages which were busy when __alloc_contig_migrate_range was called may become available by the time test_pages_isolated is called. Further, it is possible that the entire range can actually be allocated. Unfortunately, in this case the return code originally set by __alloc_contig_migrate_range (-EBUSY) is returned to the calller. Therefore, the caller assumes the range was not allocated and the pages are essentially leaked. The following patch simply updates the return code based on the value returned from test_pages_isolated. It is unlikely that we will hit this issue today based on the limited number of callers to alloc_contig_range. However, I have Cc'ed stable because if we do hit this issue it has the potential to leak a large number of pages. If the call __alloc_contig_migrate_range() in alloc_contig_range returns -EBUSY, processing continues so that test_pages_isolated() is called where there is a tracepoint to identify the busy pages. However, it is possible for busy pages to become available between the calls to these two routines. In this case, the range of pages may be allocated. Unfortunately, the original return code (ret == -EBUSY) is still set and returned to the caller. Therefore, the caller believes the pages were not allocated and they are leaked. Update the return code with the value from test_pages_isolated(). Link: http://lkml.kernel.org/r/20171120193930.23428-2-mike.kravetz@oracle.com Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Michal Nazarewicz <mina86(a)mina86.com> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak mm/page_alloc.c --- a/mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak +++ a/mm/page_alloc.c @@ -7702,10 +7702,10 @@ int alloc_contig_range(unsigned long sta } /* Make sure the range is really isolated. */ - if (test_pages_isolated(outer_start, end, false)) { + ret = test_pages_isolated(outer_start, end, false); + if (ret) { pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n", __func__, outer_start, end); - ret = -EBUSY; goto done; } _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are mm-cma-fix-alloc_contig_range-ret-code-potential-leak-v2.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] + mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine has been added to the -mm tree. Its filename is mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-fix-null-pointer-derefe… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-fix-null-pointer-derefe… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Subject: mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine I made a mistake during converting hugetlb code to 5-level paging: in huge_pte_alloc() we have to use p4d_alloc(), not p4d_offset(). Otherwise it leads to crash -- NULL-pointer dereference in pud_alloc() if p4d table is not yet allocated. It only can happen in 5-level paging mode. In 4-level paging mode p4d_offset() always returns pgd, so we are fine. Link: http://lkml.kernel.org/r/20171122121921.64822-1-kirill.shutemov@linux.intel… Fixes: c2febafc6773 ("mm: convert generic code to 5-level paging") Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> [4.11+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff -puN mm/hugetlb.c~mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine mm/hugetlb.c --- a/mm/hugetlb.c~mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine +++ a/mm/hugetlb.c @@ -4635,7 +4635,9 @@ pte_t *huge_pte_alloc(struct mm_struct * pte_t *pte = NULL; pgd = pgd_offset(mm, addr); - p4d = p4d_offset(pgd, addr); + p4d = p4d_alloc(mm, pgd, addr); + if (!p4d) + return NULL; pud = pud_alloc(mm, p4d, addr); if (pud) { if (sz == PUD_SIZE) { _ Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] + autofs-revert-fix-at_no_automount-not-being-honored.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored" has been added to the -mm tree. Its filename is autofs-revert-fix-at_no_automount-not-being-honored.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/autofs-revert-fix-at_no_automount-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/autofs-revert-fix-at_no_automount-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Ian Kent <raven(a)themaw.net> Subject: autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored" 42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored") allowed the fstatat(2) system call to properly honor the AT_NO_AUTOMOUNT flag but introduced a semantic change. In order to honor AT_NO_AUTOMOUNT a semantic change was made to the negative dentry case for stat family system calls in follow_automount(). This changed the unconditional triggering of an automount in this case to no longer be done and an error returned instead. This has caused more problems than I expected so reverting the change is needed. In a discussion with Neil Brown it was concluded that the automount(8) daemon can implement this change without kernel modifications. So that will be done instead and the autofs module documentation updated with a description of the problem and what needs to be done by module users for this specific case. Link: http://lkml.kernel.org/r/151174730120.6162.3848002191530283984.stgit@pluto.… Fixes: 42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored") Signed-off-by: Ian Kent <raven(a)themaw.net> Cc: Neil Brown <neilb(a)suse.com> Cc: Al Viro <viro(a)ZenIV.linux.org.uk> Cc: David Howells <dhowells(a)redhat.com> Cc: Colin Walters <walters(a)redhat.com> Cc: Ondrej Holy <oholy(a)redhat.com> Cc: <stable(a)vger.kernel.org> [4.11+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/namei.c | 15 +++------------ include/linux/fs.h | 3 ++- 2 files changed, 5 insertions(+), 13 deletions(-) diff -puN fs/namei.c~autofs-revert-fix-at_no_automount-not-being-honored fs/namei.c --- a/fs/namei.c~autofs-revert-fix-at_no_automount-not-being-honored +++ a/fs/namei.c @@ -1129,18 +1129,9 @@ static int follow_automount(struct path * of the daemon to instantiate them before they can be used. */ if (!(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY | - LOOKUP_OPEN | LOOKUP_CREATE | - LOOKUP_AUTOMOUNT))) { - /* Positive dentry that isn't meant to trigger an - * automount, EISDIR will allow it to be used, - * otherwise there's no mount here "now" so return - * ENOENT. - */ - if (path->dentry->d_inode) - return -EISDIR; - else - return -ENOENT; - } + LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT)) && + path->dentry->d_inode) + return -EISDIR; if (path->dentry->d_sb->s_user_ns != &init_user_ns) return -EACCES; diff -puN include/linux/fs.h~autofs-revert-fix-at_no_automount-not-being-honored include/linux/fs.h --- a/include/linux/fs.h~autofs-revert-fix-at_no_automount-not-being-honored +++ a/include/linux/fs.h @@ -3088,7 +3088,8 @@ static inline int vfs_lstat(const char _ static inline int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, int flags) { - return vfs_statx(dfd, filename, flags, stat, STATX_BASIC_STATS); + return vfs_statx(dfd, filename, flags | AT_NO_AUTOMOUNT, + stat, STATX_BASIC_STATS); } static inline int vfs_fstat(int fd, struct kstat *stat) { _ Patches currently in -mm which might be from raven(a)themaw.net are autofs-revert-take-more-care-to-not-update-last_used-on-path-walk.patch autofs-revert-fix-at_no_automount-not-being-honored.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] + autofs-revert-take-more-care-to-not-update-last_used-on-path-walk.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: autofs: revert "autofs: take more care to not update last_used on path walk" has been added to the -mm tree. Its filename is autofs-revert-take-more-care-to-not-update-last_used-on-path-walk.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/autofs-revert-take-more-care-to-no… and later at http://ozlabs.org/~akpm/mmotm/broken-out/autofs-revert-take-more-care-to-no… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Ian Kent <raven(a)themaw.net> Subject: autofs: revert "autofs: take more care to not update last_used on path walk" While 092a53452b ("autofs: take more care to not update last_used on path walk") helped (partially) resolve a problem where automounts were not expiring due to aggressive accesses from user space it has a side effect for very large environments. This change helps with the expire problem by making the expire more aggressive but, for very large environments, that means more mount requests from clients. When there are a lot of clients that can mean fairly significant server load increases. It turns out I put the last_used in this position to solve this very problem and failed to update my own thinking of the autofs expire policy. So the patch being reverted introduces a regression which should be fixed. Link: http://lkml.kernel.org/r/151174729420.6162.1832622523537052460.stgit@pluto.… Fixes: 092a53452b ("autofs: take more care to not update last_used on path walk") Signed-off-by: Ian Kent <raven(a)themaw.net> Reviewed-by: NeilBrown <neilb(a)suse.com> Cc: Al Viro <viro(a)ZenIV.linux.org.uk> Cc: <stable(a)vger.kernel.org> [4.11+] Cc: Colin Walters <walters(a)redhat.com> Cc: David Howells <dhowells(a)redhat.com> Cc: Ondrej Holy <oholy(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/autofs4/root.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff -puN fs/autofs4/root.c~autofs-revert-take-more-care-to-not-update-last_used-on-path-walk fs/autofs4/root.c --- a/fs/autofs4/root.c~autofs-revert-take-more-care-to-not-update-last_used-on-path-walk +++ a/fs/autofs4/root.c @@ -281,8 +281,8 @@ static int autofs4_mount_wait(const stru pr_debug("waiting for mount name=%pd\n", path->dentry); status = autofs4_wait(sbi, path, NFY_MOUNT); pr_debug("mount wait done status=%d\n", status); - ino->last_used = jiffies; } + ino->last_used = jiffies; return status; } @@ -321,21 +321,16 @@ static struct dentry *autofs4_mountpoint */ if (autofs_type_indirect(sbi->type) && d_unhashed(dentry)) { struct dentry *parent = dentry->d_parent; + struct autofs_info *ino; struct dentry *new; new = d_lookup(parent, &dentry->d_name); if (!new) return NULL; - if (new == dentry) - dput(new); - else { - struct autofs_info *ino; - - ino = autofs4_dentry_ino(new); - ino->last_used = jiffies; - dput(path->dentry); - path->dentry = new; - } + ino = autofs4_dentry_ino(new); + ino->last_used = jiffies; + dput(path->dentry); + path->dentry = new; } return path->dentry; } _ Patches currently in -mm which might be from raven(a)themaw.net are autofs-revert-take-more-care-to-not-update-last_used-on-path-walk.patch autofs-revert-fix-at_no_automount-not-being-honored.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] + fat-fix-sb_rdonly-change.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: fat: Fix sb_rdonly() change has been added to the -mm tree. Its filename is fat-fix-sb_rdonly-change.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/fat-fix-sb_rdonly-change.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/fat-fix-sb_rdonly-change.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Subject: fat: Fix sb_rdonly() change bc98a42c1f7d0f ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)") converted fat_remount():new_rdonly from a bool to an int. However fat_remount() depends upon the compiler's conversion of a non-zero integer into boolean `true'. Fix it by switching `new_rdonly' back into a bool. Link: http://lkml.kernel.org/r/87mv3d5x51.fsf@mail.parknet.co.jp Fixes: bc98a42c1f7d0f8 ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)") Signed-off-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Cc: Joe Perches <joe(a)perches.com> Cc: David Howells <dhowells(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/fat/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN fs/fat/inode.c~fat-fix-sb_rdonly-change fs/fat/inode.c --- a/fs/fat/inode.c~fat-fix-sb_rdonly-change +++ a/fs/fat/inode.c @@ -779,7 +779,7 @@ static void __exit fat_destroy_inodecach static int fat_remount(struct super_block *sb, int *flags, char *data) { - int new_rdonly; + bool new_rdonly; struct msdos_sb_info *sbi = MSDOS_SB(sb); *flags |= SB_NODIRATIME | (sbi->options.isvfat ? 0 : SB_NOATIME); _ Patches currently in -mm which might be from hirofumi(a)mail.parknet.co.jp are fat-fix-sb_rdonly-change.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] + revert-async-simplify-lowest_in_progress.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: kernel/async.c: revert "async: simplify lowest_in_progress()" has been added to the -mm tree. Its filename is revert-async-simplify-lowest_in_progress.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/revert-async-simplify-lowest_in_pr… and later at http://ozlabs.org/~akpm/mmotm/broken-out/revert-async-simplify-lowest_in_pr… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Subject: kernel/async.c: revert "async: simplify lowest_in_progress()" This reverts 92266d6ef60c2381 ("async: simplify lowest_in_progress()"), which was simply wrong: In the case where domain is NULL, we now use the wrong offsetof() in the list_first_entry macro, so we don't actually fetch the ->cookie value, but rather the eight bytes located sizeof(struct list_head) further into the struct async_entry. On 64 bit, that's the data member, while on 32 bit, that's a u64 built from func and data in some order. I think the bug happens to be harmless in practice: It obviously only affects callers which pass a NULL domain, and AFAICT the only such caller is async_synchronize_full() -> async_synchronize_full_domain(NULL) -> async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL) and the ASYNC_COOKIE_MAX means that in practice we end up waiting for the async_global_pending list to be empty - but it would break if somebody happened to pass (void*)-1 as the data element to async_schedule, and of course also if somebody ever does a async_synchronize_cookie_domain(, NULL) with a "finite" cookie value. Maybe the "harmless in practice" means this isn't -stable material. But I'm not completely confident my quick git grep'ing is enough, and there might be affected code in one of the earlier kernels that has since been removed, so I'll leave the decision to the stable guys. Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk Fixes: 92266d6ef60c "async: simplify lowest_in_progress()" Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Acked-by: Tejun Heo <tj(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Adam Wallis <awallis(a)codeaurora.org> Cc: Lai Jiangshan <laijs(a)cn.fujitsu.com> Cc: <stable(a)vger.kernel.org> [3.10+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/async.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff -puN kernel/async.c~revert-async-simplify-lowest_in_progress kernel/async.c --- a/kernel/async.c~revert-async-simplify-lowest_in_progress +++ a/kernel/async.c @@ -84,20 +84,24 @@ static atomic_t entry_count; static async_cookie_t lowest_in_progress(struct async_domain *domain) { - struct list_head *pending; + struct async_entry *first = NULL; async_cookie_t ret = ASYNC_COOKIE_MAX; unsigned long flags; spin_lock_irqsave(&async_lock, flags); - if (domain) - pending = &domain->pending; - else - pending = &async_global_pending; + if (domain) { + if (!list_empty(&domain->pending)) + first = list_first_entry(&domain->pending, + struct async_entry, domain_list); + } else { + if (!list_empty(&async_global_pending)) + first = list_first_entry(&async_global_pending, + struct async_entry, global_list); + } - if (!list_empty(pending)) - ret = list_first_entry(pending, struct async_entry, - domain_list)->cookie; + if (first) + ret = first->cookie; spin_unlock_irqrestore(&async_lock, flags); return ret; _ Patches currently in -mm which might be from linux(a)rasmusvillemoes.dk are revert-async-simplify-lowest_in_progress.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] + mm-memcg-fix-mem_cgroup_swapout-for-thps.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, memcg: fix mem_cgroup_swapout() for THPs has been added to the -mm tree. Its filename is mm-memcg-fix-mem_cgroup_swapout-for-thps.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-fix-mem_cgroup_swapout-fo… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-fix-mem_cgroup_swapout-fo… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Shakeel Butt <shakeelb(a)google.com> Subject: mm, memcg: fix mem_cgroup_swapout() for THPs d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP") changed mem_cgroup_swapout() to support transparent huge page (THP). However the patch missed one location which should be changed for correctly handling THPs. The resulting bug will cause the memory cgroups whose THPs were swapped out to become zombies on deletion. Link: http://lkml.kernel.org/r/20171128161941.20931-1-shakeelb@google.com Fixes: d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP") Signed-off-by: Shakeel Butt <shakeelb(a)google.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Huang Ying <ying.huang(a)intel.com> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: Greg Thelen <gthelen(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/memcontrol.c~mm-memcg-fix-mem_cgroup_swapout-for-thps mm/memcontrol.c --- a/mm/memcontrol.c~mm-memcg-fix-mem_cgroup_swapout-for-thps +++ a/mm/memcontrol.c @@ -6044,7 +6044,7 @@ void mem_cgroup_swapout(struct page *pag memcg_check_events(memcg, page); if (!mem_cgroup_is_root(memcg)) - css_put(&memcg->css); + css_put_many(&memcg->css, nr_entries); } /** _ Patches currently in -mm which might be from shakeelb(a)google.com are mm-memcg-fix-mem_cgroup_swapout-for-thps.patch mm-mlock-vmscan-no-more-skipping-pagevecs.patch vfs-remove-might_sleep-from-clear_inode.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH rdma-rc v2] IB/core: Only enforce security for InfiniBand

by Leon Romanovsky

From: Daniel Jurgens <danielj(a)mellanox.com> For now the only LSM security enforcement mechanism available is specific to InfiniBand. Bypass enforcement for non-IB link types. This fixes a regression where modify_qp fails for iWARP because querying the PKEY returns -EINVAL. Cc: Paul Moore <paul(a)paul-moore.com> Cc: Don Dutile <ddutile(a)redhat.com> Cc: stable(a)vger.kernel.org Reported-by: Potnuri Bharat Teja <bharat(a)chelsio.com> Fixes: d291f1a65232("IB/core: Enforce PKey security on QPs") Fixes: 47a2b338fe63("IB/core: Enforce security on management datagrams") Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com> Reviewed-by: Parav Pandit <parav(a)mellanox.com> Tested-by: Potnuri Bharat Teja <bharat(a)chelsio.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> --- Changelog: v1->v2: Fixed build errors v0->v1: Added proper SElinux patch --- drivers/infiniband/core/security.c | 43 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/core/security.c b/drivers/infiniband/core/security.c index 23278ed5be45..06c608c07b65 100644 --- a/drivers/infiniband/core/security.c +++ b/drivers/infiniband/core/security.c @@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec) int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev) { + u8 i = rdma_start_port(dev); + bool is_ib = false; int ret; + while (i <= rdma_end_port(dev) && !is_ib) + is_ib = rdma_protocol_ib(dev, i++); + + /* If this isn't an IB device don't create the security context */ + if (!is_ib) + return 0; + qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL); if (!qp->qp_sec) return -ENOMEM; @@ -441,6 +450,10 @@ EXPORT_SYMBOL(ib_create_qp_security); void ib_destroy_qp_security_begin(struct ib_qp_security *sec) { + /* Return if not IB */ + if (!sec) + return; + mutex_lock(&sec->mutex); /* Remove the QP from the lists so it won't get added to @@ -470,6 +483,10 @@ void ib_destroy_qp_security_abort(struct ib_qp_security *sec) int ret; int i; + /* Return if not IB */ + if (!sec) + return; + /* If a concurrent cache update is in progress this * QP security could be marked for an error state * transition. Wait for this to complete. @@ -505,6 +522,10 @@ void ib_destroy_qp_security_end(struct ib_qp_security *sec) { int i; + /* Return if not IB */ + if (!sec) + return; + /* If a concurrent cache update is occurring we must * wait until this QP security structure is processed * in the QP to error flow before destroying it because @@ -565,13 +586,19 @@ int ib_security_modify_qp(struct ib_qp *qp, bool pps_change = ((qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) || (qp_attr_mask & IB_QP_ALT_PATH)); + WARN_ONCE((qp_attr_mask & IB_QP_PORT && + rdma_protocol_ib(real_qp->device, qp_attr->port_num) && + !real_qp->qp_sec), + "%s: QP security is not initialized for IB QP: %d\n", + __func__, real_qp->qp_num); + /* The port/pkey settings are maintained only for the real QP. Open * handles on the real QP will be in the shared_qp_list. When * enforcing security on the real QP all the shared QPs will be * checked as well. */ - if (pps_change && !special_qp) { + if (pps_change && !special_qp && real_qp->qp_sec) { mutex_lock(&real_qp->qp_sec->mutex); new_pps = get_new_pps(real_qp, qp_attr, @@ -600,7 +627,7 @@ int ib_security_modify_qp(struct ib_qp *qp, qp_attr_mask, udata); - if (pps_change && !special_qp) { + if (pps_change && !special_qp && real_qp->qp_sec) { /* Clean up the lists and free the appropriate * ports_pkeys structure. */ @@ -631,6 +658,9 @@ int ib_security_pkey_access(struct ib_device *dev, u16 pkey; int ret; + if (!rdma_protocol_ib(dev, port_num)) + return 0; + ret = ib_get_cached_pkey(dev, port_num, pkey_index, &pkey); if (ret) return ret; @@ -665,6 +695,9 @@ int ib_mad_agent_security_setup(struct ib_mad_agent *agent, { int ret; + if (!rdma_protocol_ib(agent->device, agent->port_num)) + return 0; + ret = security_ib_alloc_security(&agent->security); if (ret) return ret; @@ -690,6 +723,9 @@ int ib_mad_agent_security_setup(struct ib_mad_agent *agent, void ib_mad_agent_security_cleanup(struct ib_mad_agent *agent) { + if (!rdma_protocol_ib(agent->device, agent->port_num)) + return; + security_ib_free_security(agent->security); if (agent->lsm_nb_reg) unregister_lsm_notifier(&agent->lsm_nb); @@ -697,6 +733,9 @@ void ib_mad_agent_security_cleanup(struct ib_mad_agent *agent) int ib_mad_enforce_security(struct ib_mad_agent_private *map, u16 pkey_index) { + if (!rdma_protocol_ib(map->agent.device, map->agent.port_num)) + return 0; + if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed) return -EACCES; -- 2.15.0

6 years, 6 months

3
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror