All of lore.kernel.org
 help / color / mirror / Atom feed
* [md PATCH 1/3] md/raid1: fix: IO can block resync indefinitely
From: NeilBrown @ 2016-11-08 23:21 UTC (permalink / raw)
  To: Shaohua Li; +Cc: linux-raid
In-Reply-To: <147864718560.1076.2148299631932240330.stgit@noble>

While performing a resync/recovery, raid1 divides the
array space into three regions:
 - before the resync
 - at or shortly after the resync point
 - much further ahead of the resync point.

Write requests to the first or third do not need to wait.  Write
requests to the middle region do need to wait if resync requests are
pending.

If there are any active write requests in the middle region, resync
will wait for them.

Due to an accounting error, there is a small range of addresses,
between conf->next_resync and conf->start_next_window, where write
requests will *not* be blocked, but *will* be counted in the middle
region.  This can effectively block resync indefinitely if filesystem
writes happen repeatedly to this region.

As ->next_window_requests is incremented when the sector is before
  conf->start_next_window + NEXT_NORMALIO_DISTANCE
the same boundary should be used for determining when write requests
should wait.

Signed-off-by: NeilBrown <neilb@suse.com>
---
 drivers/md/raid1.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index aac2a05cf8d1..9ac61cd85e5c 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -834,7 +834,7 @@ static bool need_to_wait_for_sync(struct r1conf *conf, struct bio *bio)
 	else if (conf->barrier && bio_data_dir(bio) == WRITE) {
 		if ((conf->mddev->curr_resync_completed
 		     >= bio_end_sector(bio)) ||
-		    (conf->next_resync + NEXT_NORMALIO_DISTANCE
+		    (conf->start_next_window + NEXT_NORMALIO_DISTANCE
 		     <= bio->bi_iter.bi_sector))
 			wait = false;
 		else



^ permalink raw reply related

* [md PATCH 0/3] Three unrelated md patches.
From: NeilBrown @ 2016-11-08 23:21 UTC (permalink / raw)
  To: Shaohua Li; +Cc: linux-raid

The first is a minor bug fix, the other to are just code improvements.
I have some patches to add "failfast" functionality, and I want to get
the small clean-ups out of the way first.

Thanks,
NeilBrown


---

NeilBrown (3):
      md/raid1: fix: IO can block resync indefinitely
      md: remove md_super_wait() call after bitmap_flush()
      md: define mddev flags, recovery flags and r1bio state bits using enums


 drivers/md/md.c    |    1 -
 drivers/md/md.h    |   76 +++++++++++++++++++++++++---------------------------
 drivers/md/raid1.c |    2 +
 drivers/md/raid1.h |   18 +++++++-----
 4 files changed, 47 insertions(+), 50 deletions(-)

--
Signature


^ permalink raw reply

* [md PATCH 2/3] md: remove md_super_wait() call after bitmap_flush()
From: NeilBrown @ 2016-11-08 23:21 UTC (permalink / raw)
  To: Shaohua Li; +Cc: linux-raid
In-Reply-To: <147864718560.1076.2148299631932240330.stgit@noble>

bitmap_flush() finishes with bitmap_update_sb(), and that finishes
with write_page(..., 1), so write_page() will wait for all writes
to complete.  So there is no point calling md_super_wait()
immediately afterwards.

Signed-off-by: NeilBrown <neilb@suse.com>
---
 drivers/md/md.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index f389d8abe137..1f1c7f007b68 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5472,7 +5472,6 @@ static void __md_stop_writes(struct mddev *mddev)
 	del_timer_sync(&mddev->safemode_timer);
 
 	bitmap_flush(mddev);
-	md_super_wait(mddev);
 
 	if (mddev->ro == 0 &&
 	    ((!mddev->in_sync && !mddev_is_clustered(mddev)) ||



^ permalink raw reply related

* Re: [PATCH 07/11] dax: Introduce IOMAP_FAULT flag
From: Dave Chinner @ 2016-11-08 23:21 UTC (permalink / raw)
  To: Jan Kara
  Cc: Ted Tso, linux-ext4, linux-fsdevel, Christoph Hellwig,
	Ross Zwisler
In-Reply-To: <1478603297-11793-8-git-send-email-jack@suse.cz>

On Tue, Nov 08, 2016 at 12:08:13PM +0100, Jan Kara wrote:
> Introduce a flag telling iomap operations whether they are handling a
> fault or other IO. That may influence behavior wrt inode size and
> similar things.
> 
> Signed-off-by: Jan Kara <jack@suse.cz>

Looks fine.

Reviewed-by: Dave Chinner <dchinner@redhat.com>

-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply

* Re: trying to get osd-scrub-repair to work on my jenkins builder
From: Willem Jan Withagen @ 2016-11-08 23:21 UTC (permalink / raw)
  To: David Zafman, Ceph Development
In-Reply-To: <68bcf424-6ec6-329e-a245-a30942f501c9@redhat.com>

On 9-11-2016 00:01, David Zafman wrote:
> 
> Willem,
> 
> At first I thought the fields were missing but I checked the xml output
> right there in get_is_making_recovery_progress() and the "xml sel" did
> see those fields while recovery was in progress.

Oke, ...

That leaves a challenge, and I'll have to review the output on FreeBSD
again, and see where, what, how it then works.

--WjW

> 
> David
> 
> 
> On 11/7/16 4:40 AM, Willem Jan Withagen wrote:
>> On 4-11-2016 18:09, Willem Jan Withagen wrote:
>>> Hi,
>>>
>>> On my workstation if have this tst completing just fine. But on my
>>> Jenkins-builder it keeps running into this state where it does not make
>>> any progress.
>>> Any particulars I should look for? I can let this run for an hour, but
>>> pg 2.0 stays active+degrades, and the script requires it to be clean.
>>> and the pgmap version is steadily incrementing.
>> And as a side-track to this, it is not where things go wrong. But it is
>> nog right either...
>>
>> ceph -c ./build/src/test/osd/testdir/osd-scrub-repair/ceph.conf --format
>> xml status 2>/dev/null | \
>>          xml sel \
>>          -t -m "//pgmap/recovering_keys_per_sec" -v . -o ' ' \
>>          -t -m "//pgmap/recovering_bytes_per_sec" -v . -o ' ' \
>>          -t -m "//pgmap/recovering_objects_per_sec" -v .)
>>      test -n "$progress"
>>
>> Does not seem to work because the output does not contain any of the xml
>> fields...
>> Now I've been beating myself over the head, but I cannot find the
>> request that does have these fields.
>>
>> So a suggestion is welcom, and I'll submit a patch.
>>
>> thanx,
>> --WjW
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


^ permalink raw reply

* [Qemu-devel] [Bug 1639394] Re: Unable to boot Solaris 8/9 x86 under Fedora 24
From: John Snow @ 2016-11-08 23:13 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20161105021624.30133.98019.malonedeb@wampee.canonical.com>

So, if I'm reading you right, Solaris10/11 work just fine, but 8/9 don't
-- and have not since qemu version 0.6.0!? From 2004?

I don't have a copy of Solaris9 to test with, so I doubt I can work on
trying to reproduce this. Is there any possibility to reproduce a
problem on an older, freely available BSD?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1639394

Title:
  Unable to boot Solaris 8/9 x86 under Fedora 24

Status in QEMU:
  New

Bug description:
  qemu-system-x86_64 -version
  QEMU emulator version 2.6.2 (qemu-2.6.2-4.fc24), Copyright (c) 2003-2008 Fabrice Bellard

  Try several ways without success, I think it was a regression because problem seems to be related with ide fixed on 0.6.0:
  - int13 CDROM BIOS fix (aka Solaris x86 install CD fix)
  - int15, ah=86 BIOS fix (aka Solaris x86 hardware probe hang up fix)

  Solaris 10/11 works without a problem, also booting with "scsi" will
  circumvent initial problem, but later found problems related with
  "scsi" cdrom boot and also will not found the "ide" disk device.

  
  qemu-system-i386 -m 712 -drive file=/dev/Virtual_hdd/beryllium0,format=raw -cdrom /repo/Isos/sol-9_905_x86.iso

  SunOS Secondary Boot version 3.00

  prom_panic: Could not mount filesystem.
  Entering boot debugger:
  [136419]

  
  Regards,
  \\CA,

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1639394/+subscriptions

^ permalink raw reply

* [obsolete] linux-next-git-rejects.patch removed from -mm tree
From: akpm @ 2016-11-08 23:20 UTC (permalink / raw)
  To: akpm, mm-commits


The patch titled
     Subject: linux-next-git-rejects
has been removed from the -mm tree.  Its filename was
     linux-next-git-rejects.patch

This patch was dropped because it is obsolete

------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: linux-next-git-rejects

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 Documentation/admin-guide/index.rst        |    3 
 arch/arc/include/asm/arcregs.h             |    4 -
 arch/arc/kernel/setup.c                    |   73 -------------------
 arch/arm/include/asm/unistd.h              |    9 --
 arch/arm/include/uapi/asm/unistd.h         |   58 ---------------
 arch/arm/mach-imx/gpc.c                    |    3 
 arch/x86/kernel/cpu/microcode/amd.c        |   14 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c     |    5 -
 drivers/gpu/drm/i915/i915_gem_fence.c      |    7 -
 drivers/gpu/drm/i915/intel_pm.c            |   12 ---
 drivers/net/ethernet/ibm/ibmvnic.c         |    3 
 drivers/net/ethernet/marvell/mv643xx_eth.c |   10 --
 drivers/spi/spi-fsl-espi.c                 |    4 -
 fs/overlayfs/copy_up.c                     |    5 -
 include/linux/netdevice.h                  |   14 ---
 include/net/udp.h                          |    3 
 net/core/dev.c                             |   10 --
 net/sunrpc/auth_gss/auth_gss.c             |    4 -
 net/sunrpc/auth_gss/gss_krb5_crypto.c      |   16 ----
 net/sunrpc/xprtrdma/svc_rdma_backchannel.c |    9 --
 20 files changed, 266 deletions(-)

diff -puN Documentation/admin-guide/index.rst~linux-next-git-rejects Documentation/admin-guide/index.rst
--- a/Documentation/admin-guide/index.rst~linux-next-git-rejects
+++ a/Documentation/admin-guide/index.rst
@@ -58,7 +58,6 @@ configure specific aspects of kernel beh
    binfmt-misc
    mono
    java
-<<<<<<< HEAD
    bad-memory
    basic-profiling
 
@@ -69,5 +68,3 @@ configure specific aspects of kernel beh
 
    * :ref:`genindex`
 
-=======
->>>>>>> doc-tweaks
diff -puN arch/arc/include/asm/arcregs.h~linux-next-git-rejects arch/arc/include/asm/arcregs.h
--- a/arch/arc/include/asm/arcregs.h~linux-next-git-rejects
+++ a/arch/arc/include/asm/arcregs.h
@@ -349,11 +349,7 @@ struct cpuinfo_arc {
 	struct cpuinfo_arc_bpu bpu;
 	struct bcr_identity core;
 	struct bcr_isa isa;
-<<<<<<< HEAD
-	const char *details, *name;
-=======
 	const void *details;
->>>>>>> linux-next/akpm-base
 	unsigned int vec_base;
 	struct cpuinfo_arc_ccm iccm, dccm;
 	struct {
diff -puN arch/arc/kernel/setup.c~linux-next-git-rejects arch/arc/kernel/setup.c
--- a/arch/arc/kernel/setup.c~linux-next-git-rejects
+++ a/arch/arc/kernel/setup.c
@@ -40,29 +40,6 @@ struct task_struct *_current_task[NR_CPU
 
 struct cpuinfo_arc cpuinfo_arc700[NR_CPUS];
 
-<<<<<<< HEAD
-static const struct id_to_str arc_cpu_rel[] = {
-#ifdef CONFIG_ISA_ARCOMPACT
-	{ 0x34, "R4.10"},
-	{ 0x35, "R4.11"},
-#else
-	{ 0x51, "R2.0" },
-	{ 0x52, "R2.1" },
-	{ 0x53, "R3.0" },
-#endif
-	{ 0x00, NULL   }
-};
-
-static const struct id_to_str arc_cpu_nm[] = {
-#ifdef CONFIG_ISA_ARCOMPACT
-	{ 0x20, "ARC 600"   },
-	{ 0x30, "ARC 770"   },  /* 750 identified seperately */
-#else
-	{ 0x40, "ARC EM"  },
-	{ 0x50, "ARC HS38"  },
-#endif
-	{ 0x00, "Unknown"   }
-=======
 static const struct cpuinfo_data arc_cpu_tbl[] = {
 #ifdef CONFIG_ISA_ARCOMPACT
 	{ {0x20, "ARC 600"      }, 0x2F},
@@ -75,7 +52,6 @@ static const struct cpuinfo_data arc_cpu
 	{ {0x53, "ARC HS38 R3.0"}, 0x53},
 #endif
 	{ {0x00, NULL		} }
->>>>>>> linux-next/akpm-base
 };
 
 static void read_decode_ccm_bcr(struct cpuinfo_arc *cpu)
@@ -130,38 +106,21 @@ static void read_arc_build_cfg_regs(void
 	struct bcr_timer timer;
 	struct bcr_generic bcr;
 	struct cpuinfo_arc *cpu = &cpuinfo_arc700[smp_processor_id()];
-<<<<<<< HEAD
-	const struct id_to_str *tbl;
-=======
 	const struct cpuinfo_data *tbl;
->>>>>>> linux-next/akpm-base
 
 	FIX_PTR(cpu);
 
 	READ_BCR(AUX_IDENTITY, cpu->core);
 	READ_BCR(ARC_REG_ISA_CFG_BCR, cpu->isa);
 
-<<<<<<< HEAD
-	for (tbl = &arc_cpu_rel[0]; tbl->id != 0; tbl++) {
-		if (cpu->core.family == tbl->id) {
-			cpu->details = tbl->str;
-=======
 	for (tbl = &arc_cpu_tbl[0]; tbl->info.id != 0; tbl++) {
 		if ((cpu->core.family >= tbl->info.id) &&
 		    (cpu->core.family <= tbl->up_range)) {
 			cpu->details = tbl;
->>>>>>> linux-next/akpm-base
 			break;
 		}
 	}
 
-<<<<<<< HEAD
-	for (tbl = &arc_cpu_nm[0]; tbl->id != 0; tbl++) {
-		if ((cpu->core.family & 0xF0) == tbl->id)
-			break;
-	}
-	cpu->name = tbl->str;
-=======
 	/* some hacks for lack of feature BCR info in old ARC700 cores */
 	if (is_isa_arcompact()) {
 		if (!cpu->isa.ver)	/* ISA BCR absent, use Kconfig info */
@@ -174,7 +133,6 @@ static void read_arc_build_cfg_regs(void
 
 	cpu->extn.swape = (cpu->core.family >= 0x34) ? 1 :
 				IS_ENABLED(CONFIG_ARC_HAS_SWAPE);
->>>>>>> linux-next/akpm-base
 
 	READ_BCR(ARC_REG_TIMERS_BCR, timer);
 	cpu->extn.timer0 = timer.t0;
@@ -243,56 +201,26 @@ static void read_arc_build_cfg_regs(void
 
 	cpu->extn.debug = cpu->extn.ap | cpu->extn.smart | cpu->extn.rtt;
 
-<<<<<<< HEAD
-	/* some hacks for lack of feature BCR info in old ARC700 cores */
-	if (is_isa_arcompact()) {
-		if (!cpu->isa.ver)	/* ISA BCR absent, use Kconfig info */
-			cpu->isa.atomic = IS_ENABLED(CONFIG_ARC_HAS_LLSC);
-		else
-			cpu->isa.atomic = cpu->isa.atomic1;
-
-		cpu->isa.be = IS_ENABLED(CONFIG_CPU_BIG_ENDIAN);
-
-		 /* there's no direct way to distinguish 750 vs. 770 */
-		if (unlikely(cpu->core.family < 0x34 || cpu->mmu.ver < 3))
-			cpu->name = "ARC750";
-	}
-}
-
-=======
->>>>>>> linux-next/akpm-base
 static char *arc_cpu_mumbojumbo(int cpu_id, char *buf, int len)
 {
 	struct cpuinfo_arc *cpu = &cpuinfo_arc700[cpu_id];
 	struct bcr_identity *core = &cpu->core;
-<<<<<<< HEAD
-=======
 	const struct cpuinfo_data *tbl = cpu->details;
 	char *isa_nm;
->>>>>>> linux-next/akpm-base
 	int i, n = 0;
 
 	FIX_PTR(cpu);
 
-<<<<<<< HEAD
-=======
 	if (is_isa_arcompact()) {
 		isa_nm = "ARCompact";
 	} else {
 		isa_nm = "ARCv2";
 	}
 
->>>>>>> linux-next/akpm-base
 	n += scnprintf(buf + n, len - n,
 		       "\nIDENTITY\t: ARCVER [%#02x] ARCNUM [%#02x] CHIPID [%#4x]\n",
 		       core->family, core->cpu_id, core->chip_id);
 
-<<<<<<< HEAD
-	n += scnprintf(buf + n, len - n, "processor [%d]\t: %s %s (%s ISA) %s\n",
-		       cpu_id, cpu->name, cpu->details,
-		       is_isa_arcompact() ? "ARCompact" : "ARCv2",
-		       IS_AVAIL1(cpu->isa.be, "[Big-Endian]"));
-=======
 	n += scnprintf(buf + n, len - n,
 				       "processor [%d]\t: %s (%s ISA) %s\n",
 				       cpu_id, tbl->info.str, isa_nm,
@@ -300,7 +228,6 @@ static char *arc_cpu_mumbojumbo(int cpu_
 
 	if (tbl->info.id == 0)
 		n += scnprintf(buf + n, len - n, "UNKNOWN ARC Processor\n");
->>>>>>> linux-next/akpm-base
 
 	n += scnprintf(buf + n, len - n, "Timers\t\t: %s%s%s%s\nISA Extn\t: ",
 		       IS_AVAIL1(cpu->extn.timer0, "Timer0 "),
diff -puN arch/arm/include/asm/unistd.h~linux-next-git-rejects arch/arm/include/asm/unistd.h
--- a/arch/arm/include/asm/unistd.h~linux-next-git-rejects
+++ a/arch/arm/include/asm/unistd.h
@@ -14,16 +14,7 @@
 #define __ASM_ARM_UNISTD_H
 
 #include <uapi/asm/unistd.h>
-<<<<<<< HEAD
-
-/*
- * This may need to be greater than __NR_last_syscall+1 in order to
- * account for the padding in the syscall table
- */
-#define __NR_syscalls  (400)
-=======
 #include <asm/unistd-nr.h>
->>>>>>> linux-next/akpm-base
 
 #define __ARCH_WANT_STAT64
 #define __ARCH_WANT_SYS_GETHOSTNAME
diff -puN arch/arm/include/uapi/asm/unistd.h~linux-next-git-rejects arch/arm/include/uapi/asm/unistd.h
--- a/arch/arm/include/uapi/asm/unistd.h~linux-next-git-rejects
+++ a/arch/arm/include/uapi/asm/unistd.h
@@ -25,64 +25,6 @@
 
 #include <asm/unistd-common.h>
 #define __NR_sync_file_range2		__NR_arm_sync_file_range
-<<<<<<< HEAD
-#define __NR_tee			(__NR_SYSCALL_BASE+342)
-#define __NR_vmsplice			(__NR_SYSCALL_BASE+343)
-#define __NR_move_pages			(__NR_SYSCALL_BASE+344)
-#define __NR_getcpu			(__NR_SYSCALL_BASE+345)
-#define __NR_epoll_pwait		(__NR_SYSCALL_BASE+346)
-#define __NR_kexec_load			(__NR_SYSCALL_BASE+347)
-#define __NR_utimensat			(__NR_SYSCALL_BASE+348)
-#define __NR_signalfd			(__NR_SYSCALL_BASE+349)
-#define __NR_timerfd_create		(__NR_SYSCALL_BASE+350)
-#define __NR_eventfd			(__NR_SYSCALL_BASE+351)
-#define __NR_fallocate			(__NR_SYSCALL_BASE+352)
-#define __NR_timerfd_settime		(__NR_SYSCALL_BASE+353)
-#define __NR_timerfd_gettime		(__NR_SYSCALL_BASE+354)
-#define __NR_signalfd4			(__NR_SYSCALL_BASE+355)
-#define __NR_eventfd2			(__NR_SYSCALL_BASE+356)
-#define __NR_epoll_create1		(__NR_SYSCALL_BASE+357)
-#define __NR_dup3			(__NR_SYSCALL_BASE+358)
-#define __NR_pipe2			(__NR_SYSCALL_BASE+359)
-#define __NR_inotify_init1		(__NR_SYSCALL_BASE+360)
-#define __NR_preadv			(__NR_SYSCALL_BASE+361)
-#define __NR_pwritev			(__NR_SYSCALL_BASE+362)
-#define __NR_rt_tgsigqueueinfo		(__NR_SYSCALL_BASE+363)
-#define __NR_perf_event_open		(__NR_SYSCALL_BASE+364)
-#define __NR_recvmmsg			(__NR_SYSCALL_BASE+365)
-#define __NR_accept4			(__NR_SYSCALL_BASE+366)
-#define __NR_fanotify_init		(__NR_SYSCALL_BASE+367)
-#define __NR_fanotify_mark		(__NR_SYSCALL_BASE+368)
-#define __NR_prlimit64			(__NR_SYSCALL_BASE+369)
-#define __NR_name_to_handle_at		(__NR_SYSCALL_BASE+370)
-#define __NR_open_by_handle_at		(__NR_SYSCALL_BASE+371)
-#define __NR_clock_adjtime		(__NR_SYSCALL_BASE+372)
-#define __NR_syncfs			(__NR_SYSCALL_BASE+373)
-#define __NR_sendmmsg			(__NR_SYSCALL_BASE+374)
-#define __NR_setns			(__NR_SYSCALL_BASE+375)
-#define __NR_process_vm_readv		(__NR_SYSCALL_BASE+376)
-#define __NR_process_vm_writev		(__NR_SYSCALL_BASE+377)
-#define __NR_kcmp			(__NR_SYSCALL_BASE+378)
-#define __NR_finit_module		(__NR_SYSCALL_BASE+379)
-#define __NR_sched_setattr		(__NR_SYSCALL_BASE+380)
-#define __NR_sched_getattr		(__NR_SYSCALL_BASE+381)
-#define __NR_renameat2			(__NR_SYSCALL_BASE+382)
-#define __NR_seccomp			(__NR_SYSCALL_BASE+383)
-#define __NR_getrandom			(__NR_SYSCALL_BASE+384)
-#define __NR_memfd_create		(__NR_SYSCALL_BASE+385)
-#define __NR_bpf			(__NR_SYSCALL_BASE+386)
-#define __NR_execveat			(__NR_SYSCALL_BASE+387)
-#define __NR_userfaultfd		(__NR_SYSCALL_BASE+388)
-#define __NR_membarrier			(__NR_SYSCALL_BASE+389)
-#define __NR_mlock2			(__NR_SYSCALL_BASE+390)
-#define __NR_copy_file_range		(__NR_SYSCALL_BASE+391)
-#define __NR_preadv2			(__NR_SYSCALL_BASE+392)
-#define __NR_pwritev2			(__NR_SYSCALL_BASE+393)
-#define __NR_pkey_mprotect		(__NR_SYSCALL_BASE+394)
-#define __NR_pkey_alloc			(__NR_SYSCALL_BASE+395)
-#define __NR_pkey_free			(__NR_SYSCALL_BASE+396)
-=======
->>>>>>> linux-next/akpm-base
 
 /*
  * The following SWIs are ARM private.
diff -puN arch/arm/mach-imx/gpc.c~linux-next-git-rejects arch/arm/mach-imx/gpc.c
--- a/arch/arm/mach-imx/gpc.c~linux-next-git-rejects
+++ a/arch/arm/mach-imx/gpc.c
@@ -423,8 +423,6 @@ static int imx_gpc_genpd_init(struct dev
 	if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
 		return 0;
 
-<<<<<<< HEAD
-=======
 	imx6q_pu_domain.base.states = devm_kzalloc(dev,
 					sizeof(*imx6q_pu_domain.base.states),
 					GFP_KERNEL);
@@ -435,7 +433,6 @@ static int imx_gpc_genpd_init(struct dev
 	imx6q_pu_domain.base.states[0].power_on_latency_ns = 2000000;
 	imx6q_pu_domain.base.state_count = 1;
 
->>>>>>> linux-next/akpm-base
 	for (i = 0; i < ARRAY_SIZE(imx_gpc_domains); i++)
 		pm_genpd_init(imx_gpc_domains[i], NULL, false);
 
diff -puN arch/x86/kernel/cpu/microcode/amd.c~linux-next-git-rejects arch/x86/kernel/cpu/microcode/amd.c
--- a/arch/x86/kernel/cpu/microcode/amd.c~linux-next-git-rejects
+++ a/arch/x86/kernel/cpu/microcode/amd.c
@@ -433,23 +433,9 @@ int __init save_microcode_in_initrd_amd(
 		if (IS_ENABLED(CONFIG_X86_32) && (cont.size != -1)) {
 			struct cpio_data cp = { NULL, 0, "" };
 
-<<<<<<< HEAD
-#ifdef CONFIG_X86_32
-	get_bsp_sig();
-	cont	= (unsigned long)container;
-	cont_va = __va(container);
-#else
-	/*
-	 * We need the physical address of the container for both bitness since
-	 * boot_params.hdr.ramdisk_image is a physical address.
-	 */
-	cont    = __pa_nodebug(container);
-	cont_va = container;
-=======
 #ifdef CONFIG_BLK_DEV_INITRD
 			cp = find_cpio_data(ucode_path, (void *)initrd_start,
 					    initrd_end - initrd_start, NULL);
->>>>>>> linux-next/akpm-base
 #endif
 
 			if (!(cp.data && cp.size)) {
diff -puN drivers/net/ethernet/ibm/ibmvnic.c~linux-next-git-rejects drivers/net/ethernet/ibm/ibmvnic.c
--- a/drivers/net/ethernet/ibm/ibmvnic.c~linux-next-git-rejects
+++ a/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3659,11 +3659,8 @@ static void handle_crq_init_rsp(struct w
 
 	netdev->real_num_tx_queues = adapter->req_tx_queues;
 	netdev->mtu = adapter->req_mtu;
-<<<<<<< HEAD
-=======
 	netdev->min_mtu = adapter->min_mtu;
 	netdev->max_mtu = adapter->max_mtu;
->>>>>>> linux-next/akpm-base
 
 	if (adapter->failover) {
 		adapter->failover = false;
diff -puN drivers/net/ethernet/marvell/mv643xx_eth.c~linux-next-git-rejects drivers/net/ethernet/marvell/mv643xx_eth.c
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c~linux-next-git-rejects
+++ a/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -3160,17 +3160,10 @@ static int mv643xx_eth_probe(struct plat
 
 	err = 0;
 	if (pd->phy_node) {
-<<<<<<< HEAD
-		mp->phy = of_phy_connect(mp->dev, pd->phy_node,
-					 mv643xx_eth_adjust_link, 0,
-					 get_phy_mode(mp));
-		if (!mp->phy)
-=======
 		phydev = of_phy_connect(mp->dev, pd->phy_node,
 					mv643xx_eth_adjust_link, 0,
 					PHY_INTERFACE_MODE_GMII);
 		if (!phydev)
->>>>>>> linux-next/akpm-base
 			err = -ENODEV;
 		else
 			phy_addr_set(mp, phydev->mdio.addr);
@@ -3227,15 +3220,12 @@ static int mv643xx_eth_probe(struct plat
 	dev->priv_flags |= IFF_UNICAST_FLT;
 	dev->gso_max_segs = MV643XX_MAX_TSO_SEGS;
 
-<<<<<<< HEAD
-=======
 	/* MTU range: 64 - 9500 */
 	dev->min_mtu = 64;
 	dev->max_mtu = 9500;
 
 	SET_NETDEV_DEV(dev, &pdev->dev);
 
->>>>>>> linux-next/akpm-base
 	if (mp->shared->win_protect)
 		wrl(mp, WINDOW_PROTECT(mp->port_num), mp->shared->win_protect);
 
diff -puN drivers/spi/spi-fsl-espi.c~linux-next-git-rejects drivers/spi/spi-fsl-espi.c
--- a/drivers/spi/spi-fsl-espi.c~linux-next-git-rejects
+++ a/drivers/spi/spi-fsl-espi.c
@@ -455,11 +455,7 @@ static void fsl_espi_cpu_irq(struct mpc8
 
 		mspi->len -= rx_nr_bytes;
 
-<<<<<<< HEAD
-		if (rx_nr_bytes && mspi->rx)
-=======
 		if (rx_nr_bytes && mspi->rx) {
->>>>>>> linux-next/akpm-base
 			mspi->get_rx(rx_data, mspi);
 			mspi->rx += 4;
 		}
diff -puN include/linux/netdevice.h~linux-next-git-rejects include/linux/netdevice.h
--- a/include/linux/netdevice.h~linux-next-git-rejects
+++ a/include/linux/netdevice.h
@@ -3841,19 +3841,6 @@ struct net_device *netdev_all_lower_get_
 struct net_device *netdev_all_lower_get_next_rcu(struct net_device *dev,
 						 struct list_head **iter);
 
-<<<<<<< HEAD
-#define netdev_for_each_all_lower_dev(dev, ldev, iter) \
-	for (iter = (dev)->all_adj_list.lower.next, \
-	     ldev = netdev_all_lower_get_next(dev, &(iter)); \
-	     ldev; \
-	     ldev = netdev_all_lower_get_next(dev, &(iter)))
-
-#define netdev_for_each_all_lower_dev_rcu(dev, ldev, iter) \
-	for (iter = &(dev)->all_adj_list.lower, \
-	     ldev = netdev_all_lower_get_next_rcu(dev, &(iter)); \
-	     ldev; \
-	     ldev = netdev_all_lower_get_next_rcu(dev, &(iter)))
-=======
 int netdev_walk_all_lower_dev(struct net_device *dev,
 			      int (*fn)(struct net_device *lower_dev,
 					void *data),
@@ -3862,7 +3849,6 @@ int netdev_walk_all_lower_dev_rcu(struct
 				  int (*fn)(struct net_device *lower_dev,
 					    void *data),
 				  void *data);
->>>>>>> linux-next/akpm-base
 
 void *netdev_adjacent_get_private(struct list_head *adj_list);
 void *netdev_lower_get_first_private_rcu(struct net_device *dev);
diff -puN include/net/udp.h~linux-next-git-rejects include/net/udp.h
--- a/include/net/udp.h~linux-next-git-rejects
+++ a/include/net/udp.h
@@ -261,10 +261,7 @@ void udp_flush_pending_frames(struct soc
 void udp4_hwcsum(struct sk_buff *skb, __be32 src, __be32 dst);
 int udp_rcv(struct sk_buff *skb);
 int udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
-<<<<<<< HEAD
-=======
 int udp_init_sock(struct sock *sk);
->>>>>>> linux-next/akpm-base
 int __udp_disconnect(struct sock *sk, int flags);
 int udp_disconnect(struct sock *sk, int flags);
 unsigned int udp_poll(struct file *file, struct socket *sock, poll_table *wait);
diff -puN net/core/dev.c~linux-next-git-rejects net/core/dev.c
--- a/net/core/dev.c~linux-next-git-rejects
+++ a/net/core/dev.c
@@ -5446,15 +5446,6 @@ static struct net_device *netdev_next_lo
 	struct netdev_adjacent *lower;
 
 	lower = list_entry_rcu((*iter)->next, struct netdev_adjacent, list);
-<<<<<<< HEAD
-
-	if (&lower->list == &dev->all_adj_list.lower)
-		return NULL;
-
-	*iter = &lower->list;
-
-	return lower->dev;
-=======
 	if (&lower->list == &dev->adj_list.lower)
 		return NULL;
 
@@ -5488,7 +5479,6 @@ int netdev_walk_all_lower_dev_rcu(struct
 	}
 
 	return 0;
->>>>>>> linux-next/akpm-base
 }
 EXPORT_SYMBOL_GPL(netdev_walk_all_lower_dev_rcu);
 
diff -puN drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c~linux-next-git-rejects drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c~linux-next-git-rejects
+++ a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1758,11 +1758,6 @@ void amdgpu_vm_manager_fini(struct amdgp
 
 		dma_fence_put(adev->vm_manager.ids[i].first);
 		amdgpu_sync_free(&adev->vm_manager.ids[i].active);
-<<<<<<< HEAD
-		fence_put(id->flushed_updates);
-		fence_put(id->last_flush);
-=======
 		dma_fence_put(id->flushed_updates);
->>>>>>> linux-next/akpm-base
 	}
 }
diff -puN drivers/gpu/drm/i915/i915_gem_fence.c~linux-next-git-rejects drivers/gpu/drm/i915/i915_gem_fence.c
--- a/drivers/gpu/drm/i915/i915_gem_fence.c~linux-next-git-rejects
+++ a/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -343,12 +343,9 @@ i915_vma_get_fence(struct i915_vma *vma)
 	struct drm_i915_fence_reg *fence;
 	struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
 
-<<<<<<< HEAD
-=======
 	/* Note that we revoke fences on runtime suspend. Therefore the user
 	 * must keep the device awake whilst using the fence.
 	 */
->>>>>>> linux-next/akpm-base
 	assert_rpm_wakelock_held(to_i915(vma->vm->dev));
 
 	/* Just update our place in the LRU if our fence is getting reused. */
@@ -398,11 +395,7 @@ void i915_gem_restore_fences(struct drm_
 		 */
 		if (vma && !i915_gem_object_is_tiled(vma->obj)) {
 			GEM_BUG_ON(!reg->dirty);
-<<<<<<< HEAD
-			GEM_BUG_ON(vma->obj->fault_mappable);
-=======
 			GEM_BUG_ON(!list_empty(&vma->obj->userfault_link));
->>>>>>> linux-next/akpm-base
 
 			list_move(&reg->link, &dev_priv->mm.fence_list);
 			vma->fence = NULL;
diff -puN drivers/gpu/drm/i915/intel_pm.c~linux-next-git-rejects drivers/gpu/drm/i915/intel_pm.c
--- a/drivers/gpu/drm/i915/intel_pm.c~linux-next-git-rejects
+++ a/drivers/gpu/drm/i915/intel_pm.c
@@ -3401,11 +3401,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_
 		return 0;
 
 	if (!cstate->base.active) {
-<<<<<<< HEAD
-		ddb->pipe[pipe].start = ddb->pipe[pipe].end = 0;
-=======
 		alloc->start = alloc->end = 0;
->>>>>>> linux-next/akpm-base
 		return 0;
 	}
 
@@ -3766,13 +3762,6 @@ skl_compute_linetime_wm(struct intel_crt
 	if (!cstate->base.active)
 		return 0;
 
-<<<<<<< HEAD
-	if (WARN_ON(ilk_pipe_pixel_rate(cstate) == 0))
-		return 0;
-
-	return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
-			    ilk_pipe_pixel_rate(cstate));
-=======
 	pixel_rate = ilk_pipe_pixel_rate(cstate);
 
 	if (WARN_ON(pixel_rate == 0))
@@ -3780,7 +3769,6 @@ skl_compute_linetime_wm(struct intel_crt
 
 	return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
 			    pixel_rate);
->>>>>>> linux-next/akpm-base
 }
 
 static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
diff -puN fs/overlayfs/copy_up.c~linux-next-git-rejects fs/overlayfs/copy_up.c
--- a/fs/overlayfs/copy_up.c~linux-next-git-rejects
+++ a/fs/overlayfs/copy_up.c
@@ -185,12 +185,7 @@ static int ovl_copy_up_data(struct path
 		len -= bytes;
 	}
 
-<<<<<<< HEAD
-	if (!error)
-		error = vfs_fsync(new_file, 0);
-=======
 out:
->>>>>>> linux-next/akpm-base
 	fput(new_file);
 out_fput:
 	fput(old_file);
diff -puN net/sunrpc/auth_gss/auth_gss.c~linux-next-git-rejects net/sunrpc/auth_gss/auth_gss.c
--- a/net/sunrpc/auth_gss/auth_gss.c~linux-next-git-rejects
+++ a/net/sunrpc/auth_gss/auth_gss.c
@@ -1631,11 +1631,7 @@ gss_validate(struct rpc_task *task, __be
 		goto out_bad;
 	if (flav != RPC_AUTH_GSS)
 		goto out_bad;
-<<<<<<< HEAD
-	seq = kmalloc(4, GFP_NOFS);
-=======
 	seq = kmalloc(4, GFP_KERNEL);
->>>>>>> linux-next/akpm-base
 	if (!seq)
 		goto out_bad;
 	*seq = htonl(task->tk_rqstp->rq_seqno);
diff -puN net/sunrpc/auth_gss/gss_krb5_crypto.c~linux-next-git-rejects net/sunrpc/auth_gss/gss_krb5_crypto.c
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c~linux-next-git-rejects
+++ a/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -187,11 +187,7 @@ make_checksum_hmac_md5(struct krb5_ctx *
 		return GSS_S_FAILURE;
 	}
 
-<<<<<<< HEAD
-	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_NOFS);
-=======
 	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
->>>>>>> linux-next/akpm-base
 	if (!checksumdata)
 		return GSS_S_FAILURE;
 
@@ -295,11 +291,7 @@ make_checksum(struct krb5_ctx *kctx, cha
 		return GSS_S_FAILURE;
 	}
 
-<<<<<<< HEAD
-	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_NOFS);
-=======
 	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
->>>>>>> linux-next/akpm-base
 	if (checksumdata == NULL)
 		return GSS_S_FAILURE;
 
@@ -396,11 +388,7 @@ make_checksum_v2(struct krb5_ctx *kctx,
 		return GSS_S_FAILURE;
 	}
 
-<<<<<<< HEAD
-	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_NOFS);
-=======
 	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
->>>>>>> linux-next/akpm-base
 	if (!checksumdata)
 		return GSS_S_FAILURE;
 
@@ -696,11 +684,7 @@ gss_krb5_cts_crypt(struct crypto_skciphe
 		WARN_ON(0);
 		return -ENOMEM;
 	}
-<<<<<<< HEAD
-	data = kmalloc(GSS_KRB5_MAX_BLOCKSIZE * 2, GFP_NOFS);
-=======
 	data = kmalloc(GSS_KRB5_MAX_BLOCKSIZE * 2, GFP_KERNEL);
->>>>>>> linux-next/akpm-base
 	if (!data)
 		return -ENOMEM;
 
diff -puN net/sunrpc/xprtrdma/svc_rdma_backchannel.c~linux-next-git-rejects net/sunrpc/xprtrdma/svc_rdma_backchannel.c
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c~linux-next-git-rejects
+++ a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -182,16 +182,7 @@ xprt_rdma_bc_allocate(struct rpc_task *t
 	if (!page)
 		return -ENOMEM;
 	rqst->rq_buffer = page_address(page);
-<<<<<<< HEAD
-
-	rqst->rq_rbuffer = kmalloc(rqst->rq_rcvsize, RPCRDMA_DEF_GFP);
-	if (!rqst->rq_rbuffer) {
-		put_page(page);
-		return -ENOMEM;
-	}
-=======
 	rqst->rq_rbuffer = (char *)rqst->rq_buffer + rqst->rq_callsize;
->>>>>>> linux-next/akpm-base
 	return 0;
 }
 
_

Patches currently in -mm which might be from akpm@linux-foundation.org are

i-need-old-gcc.patch
arm-arch-arm-include-asm-pageh-needs-personalityh.patch
prctl-remove-one-shot-limitation-for-changing-exe-link-fix.patch
mm.patch
mm-compaction-allow-compaction-for-gfp_nofs-requests-fix.patch
mm-mempolicy-clean-up-__gfp_thisnode-confusion-in-policy_zonelist-checkpatch-fixes.patch
mm-unexport-__get_user_pages_unlocked-checkpatch-fixes.patch
scripts-checkpatchpl-fix-spelling.patch
debug-more-properly-delay-for-secondary-cpus-fix.patch
ipc-sem-rework-task-wakeups-checkpatch-fixes.patch
ipc-sem-optimize-perform_atomic_semop-checkpatch-fixes.patch
drivers-net-wireless-intel-iwlwifi-dvm-calibc-fix-min-warning.patch
kernel-forkc-export-kernel_thread-to-modules.patch
slab-leaks3-default-y.patch


^ permalink raw reply

* [PATCH nft] segtree: keep element comments in set intervals
From: Pablo Neira Ayuso @ 2016-11-08 23:19 UTC (permalink / raw)
  To: netfilter-devel; +Cc: netfilter

The conversion from the set element range representation to element
intervals doesn't keep the comment information around.

Fixes: https://bugzilla.netfilter.org/show_bug.cgi?id=1090
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 src/segtree.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/segtree.c b/src/segtree.c
index fa11967adbd2..32e071f6b5e8 100644
--- a/src/segtree.c
+++ b/src/segtree.c
@@ -522,9 +522,13 @@ static void set_insert_interval(struct expr *set, struct seg_tree *tree,
 	mpz_set(expr->value, ei->left);
 	expr = set_elem_expr_alloc(&internal_location, expr);
 
-	if (ei->expr != NULL && ei->expr->ops->type == EXPR_MAPPING)
-		expr = mapping_expr_alloc(&ei->expr->location, expr,
-					  expr_get(ei->expr->right));
+	if (ei->expr != NULL) {
+		if (ei->expr->comment)
+			expr->comment = xstrdup(ei->expr->comment);
+		if (ei->expr->ops->type == EXPR_MAPPING)
+			expr = mapping_expr_alloc(&ei->expr->location, expr,
+						  expr_get(ei->expr->right));
+	}
 
 	if (ei->flags & EI_F_INTERVAL_END)
 		expr->flags |= EXPR_F_INTERVAL_END;
-- 
2.1.4


^ permalink raw reply related

* Re: [PATCH net v2 2/4] net: ethernet: ti: cpsw: fix device and of_node leaks
From: Grygorii Strashko @ 2016-11-08 23:19 UTC (permalink / raw)
  To: Johan Hovold, Florian Fainelli, Mugunthan V N, Yisen Zhuang,
	Salil Mehta, David S. Miller
  Cc: netdev, linux-kernel, linux-omap
In-Reply-To: <1478194822-29545-3-git-send-email-johan@kernel.org>



On 11/03/2016 12:40 PM, Johan Hovold wrote:
> Make sure to drop the references taken by of_get_child_by_name() and
> bus_find_device() before returning from cpsw_phy_sel().
>
> Note that holding a reference to the cpsw-phy-sel device does not
> prevent the devres-managed private data from going away.
>
> Fixes: 5892cd135e16 ("drivers: net: cpsw-phy-sel: Add new driver...")
> Cc: Mugunthan V N <mugunthanvnm@ti.com>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> Cc: linux-omap@vger.kernel.org
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---

Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>

>  drivers/net/ethernet/ti/cpsw-phy-sel.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> index 054a8dd23dae..ba1e45ff6aae 100644
> --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
> +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> @@ -176,9 +176,12 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
>  	}
>
>  	dev = bus_find_device(&platform_bus_type, NULL, node, match);
> +	of_node_put(node);
>  	priv = dev_get_drvdata(dev);
>
>  	priv->cpsw_phy_sel(priv, phy_mode, slave);
> +
> +	put_device(dev);
>  }
>  EXPORT_SYMBOL_GPL(cpsw_phy_sel);
>
>

-- 
regards,
-grygorii

^ permalink raw reply

* Re: [PATCH net v2 2/4] net: ethernet: ti: cpsw: fix device and of_node leaks
From: Grygorii Strashko @ 2016-11-08 23:19 UTC (permalink / raw)
  To: Johan Hovold, Florian Fainelli, Mugunthan V N, Yisen Zhuang,
	Salil Mehta, David S. Miller
  Cc: netdev, linux-kernel, linux-omap
In-Reply-To: <1478194822-29545-3-git-send-email-johan@kernel.org>



On 11/03/2016 12:40 PM, Johan Hovold wrote:
> Make sure to drop the references taken by of_get_child_by_name() and
> bus_find_device() before returning from cpsw_phy_sel().
>
> Note that holding a reference to the cpsw-phy-sel device does not
> prevent the devres-managed private data from going away.
>
> Fixes: 5892cd135e16 ("drivers: net: cpsw-phy-sel: Add new driver...")
> Cc: Mugunthan V N <mugunthanvnm@ti.com>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> Cc: linux-omap@vger.kernel.org
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---

Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>

>  drivers/net/ethernet/ti/cpsw-phy-sel.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> index 054a8dd23dae..ba1e45ff6aae 100644
> --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
> +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> @@ -176,9 +176,12 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
>  	}
>
>  	dev = bus_find_device(&platform_bus_type, NULL, node, match);
> +	of_node_put(node);
>  	priv = dev_get_drvdata(dev);
>
>  	priv->cpsw_phy_sel(priv, phy_mode, slave);
> +
> +	put_device(dev);
>  }
>  EXPORT_SYMBOL_GPL(cpsw_phy_sel);
>
>

-- 
regards,
-grygorii

^ permalink raw reply

* Re: [PATCH V3 1/2] powerpc: Define new ISA v3.00 logical PVR value and PCR register value
From: Suraj Jitindar Singh @ 2016-11-08 23:18 UTC (permalink / raw)
  To: Michael Ellerman, linuxppc-dev; +Cc: kvm-ppc, benh, paulus, agraf
In-Reply-To: <87y40ujsam.fsf@concordia.ellerman.id.au>

On Tue, 2016-11-08 at 19:21 +1100, Michael Ellerman wrote:
> Suraj Jitindar Singh <sjitindarsingh@gmail.com> writes:
> 
> > 
> > ISA 3.00 adds the logical PVR value 0x0f000005, so add a definition
> > for
> > this.
> > 
> > Define PCR_ARCH_207 to reflect ISA 2.07 compatibility mode in the
> > processor
> > compatibility register (PCR). Also define a dummy ISA 3.00
> > compatibility
> > mode PCR_ARCH_300 to be used in the next patch to help with
> > determining the
> > PCR value.
> What's "dummy" about the PCR value?
Then next patch needs some PCR bit to specify that we want to emulate
v3.00 and/or that the host can emulate v3.00 to follow the pattern used
to determine that the host is capable of emulating the given compat
level and for determining which PCR bits to set. But no such bit is
defined for V3.00 compat mode yet so a "dummy" one is used to represent
this even though it's never defined in the ISA.
> 
> AFAICS that value is reserved in the ISA.
Yes it is a reserved bit in the PCR register but it will never actually
be set, it will always be cleared by "host_pcr_bit - guest_pcr_bit;"
> 
> Are we assuming/hoping that ISA 4.0 will use 0x10 to mean ISA 3.0 ?
Basically yes, and although I know nothing's given, it would follow the
current pattern for whatever the next ISA version is to use 0x10 to
mean V3.00 compat mode. Otherwise this will need to be updated at some
point when that's released... In fact if the compat bits are no longer
sequential this will need rewriting.
> 
> cheers

^ permalink raw reply

* Re: [PATCH V3 1/2] powerpc: Define new ISA v3.00 logical PVR value and PCR register value
From: Suraj Jitindar Singh @ 2016-11-08 23:18 UTC (permalink / raw)
  To: Michael Ellerman, linuxppc-dev; +Cc: kvm-ppc, benh, paulus, agraf
In-Reply-To: <87y40ujsam.fsf@concordia.ellerman.id.au>

On Tue, 2016-11-08 at 19:21 +1100, Michael Ellerman wrote:
> Suraj Jitindar Singh <sjitindarsingh@gmail.com> writes:
> 
> > 
> > ISA 3.00 adds the logical PVR value 0x0f000005, so add a definition
> > for
> > this.
> > 
> > Define PCR_ARCH_207 to reflect ISA 2.07 compatibility mode in the
> > processor
> > compatibility register (PCR). Also define a dummy ISA 3.00
> > compatibility
> > mode PCR_ARCH_300 to be used in the next patch to help with
> > determining the
> > PCR value.
> What's "dummy" about the PCR value?
Then next patch needs some PCR bit to specify that we want to emulate
v3.00 and/or that the host can emulate v3.00 to follow the pattern used
to determine that the host is capable of emulating the given compat
level and for determining which PCR bits to set. But no such bit is
defined for V3.00 compat mode yet so a "dummy" one is used to represent
this even though it's never defined in the ISA.
> 
> AFAICS that value is reserved in the ISA.
Yes it is a reserved bit in the PCR register but it will never actually
be set, it will always be cleared by "host_pcr_bit - guest_pcr_bit;"
> 
> Are we assuming/hoping that ISA 4.0 will use 0x10 to mean ISA 3.0 ?
Basically yes, and although I know nothing's given, it would follow the
current pattern for whatever the next ISA version is to use 0x10 to
mean V3.00 compat mode. Otherwise this will need to be updated at some
point when that's released... In fact if the compat bits are no longer
sequential this will need rewriting.
> 
> cheers

^ permalink raw reply

* [U-Boot] Issues coupling am335x with VSC8601 PHY
From: Alex @ 2016-11-08 23:18 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <0c3d0319-ffda-2873-3bdf-2586ddac06c2@adaptrum.com>

On 11/05/2016 12:07 AM, Alex wrote:
> Hi,
>
> I'm trying to enable ethernet on a custom board with an am335x soc, and
> a VSC8601 connected through RGMII. The plan is to use u-boot as a first
> stage loader to load a proprietary application (called "the app"). The
> app already has its own ethernet stack and drivers, and can successfully
> do network talk.

Okay, we solved it -- sort of. I learned the hard way that the 
EEPROM-based config mechanism in SPL chose to not configure anything -- 
no clocks, no PMIC. Once we got that hacked out[1], the ethernet started 
graciously working.

There isn't an EEPROM on these boards. Other than hacking a bunch of if 
statements, is there another mechanism to get the proper DDR, pinmux, 
PMIC, and clock configuration in SPL

Alex

[1]
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index fc1353a..159def3 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -254,7 +254,7 @@ void am33xx_spl_board_init(void)
         /* Get the frequency */
         dpll_mpu_opp100.m = am335x_get_efuse_mpu_max_freq(cdev);

-       if (board_is_bone() || board_is_bone_lt()) {
+       if (1 || board_is_bone() || board_is_bone_lt()) {
                 /* BeagleBone PMIC Code */
                 int usb_cur_lim;

@@ -262,7 +262,7 @@ void am33xx_spl_board_init(void)
                  * Only perform PMIC configurations if board rev > A1
                  * on Beaglebone White
                  */
-               if (board_is_bone() && !strncmp(board_ti_get_rev(), 
"00A1", 4))
+               if (0 &&( board_is_bone() && 
!strncmp(board_ti_get_rev(), "00A1", 4)))
                         return;

                 if (i2c_probe(TPS65217_CHIP_PM))
@@ -328,7 +328,7 @@ void am33xx_spl_board_init(void)
                  * Set LDO3, LDO4 output voltage to 3.3V for Beaglebone.
                  * Set LDO3 to 1.8V and LDO4 to 3.3V for Beaglebone Black.
                  */
-               if (board_is_bone()) {
+               if (1 || board_is_bone()) {
                         if (tps65217_reg_write(TPS65217_PROT_LEVEL_2,
                                                TPS65217_DEFLS1,
 
TPS65217_LDO_VOLTAGE_OUT_3_3,
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 27979bd..e758429 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -352,7 +352,7 @@ void enable_board_pin_mux(void)
  #else
                 configure_module_pin_mux(mmc1_pin_mux);
  #endif
-       } else if (board_is_gp_evm()) {
+       } else if (1 || board_is_gp_evm()) {
                 /* General Purpose EVM */
                 unsigned short profile = detect_daughter_board_profile();
                 configure_module_pin_mux(rgmii1_pin_mux);

^ permalink raw reply related

* + mm-slab-faster-active-and-free-stats.patch added to -mm tree
From: akpm @ 2016-11-08 23:18 UTC (permalink / raw)
  To: gthelen, cl, iamjoonsoo.kim, penberg, rientjes, mm-commits


The patch titled
     Subject: mm, slab: faster active and free stats
has been added to the -mm tree.  Its filename is
     mm-slab-faster-active-and-free-stats.patch

This patch should soon appear at
    http://ozlabs.org/~akpm/mmots/broken-out/mm-slab-faster-active-and-free-stats.patch
and later at
    http://ozlabs.org/~akpm/mmotm/broken-out/mm-slab-faster-active-and-free-stats.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: Greg Thelen <gthelen@google.com>
Subject: mm, slab: faster active and free stats

Reading /proc/slabinfo or monitoring slabtop(1) can become very expensive
if there are many slab caches and if there are very lengthy per-node
partial and/or free lists.

Commit 07a63c41fa1f ("mm/slab: improve performance of gathering slabinfo
stats") addressed the per-node full lists which showed a significant
improvement when no objects were freed.  This patch has the same
motivation and optimizes the remainder of the usecases where there are
very lengthy partial and free lists.

This patch maintains per-node active_slabs (full and partial) and
free_slabs rather than iterating the lists at runtime when reading
/proc/slabinfo.

[rientjes@google.com: changelog]
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1611081505240.13403@chino.kir.corp.google.com
Signed-off-by: Greg Thelen <gthelen@google.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/slab.c |  117 ++++++++++++++++++++--------------------------------
 mm/slab.h |    3 -
 2 files changed, 49 insertions(+), 71 deletions(-)

diff -puN mm/slab.c~mm-slab-faster-active-and-free-stats mm/slab.c
--- a/mm/slab.c~mm-slab-faster-active-and-free-stats
+++ a/mm/slab.c
@@ -227,13 +227,14 @@ static void kmem_cache_node_init(struct
 	INIT_LIST_HEAD(&parent->slabs_full);
 	INIT_LIST_HEAD(&parent->slabs_partial);
 	INIT_LIST_HEAD(&parent->slabs_free);
+	parent->active_slabs = 0;
+	parent->free_slabs = 0;
 	parent->shared = NULL;
 	parent->alien = NULL;
 	parent->colour_next = 0;
 	spin_lock_init(&parent->list_lock);
 	parent->free_objects = 0;
 	parent->free_touched = 0;
-	parent->num_slabs = 0;
 }
 
 #define MAKE_LIST(cachep, listp, slab, nodeid)				\
@@ -1366,7 +1367,6 @@ slab_out_of_memory(struct kmem_cache *ca
 {
 #if DEBUG
 	struct kmem_cache_node *n;
-	struct page *page;
 	unsigned long flags;
 	int node;
 	static DEFINE_RATELIMIT_STATE(slab_oom_rs, DEFAULT_RATELIMIT_INTERVAL,
@@ -1381,32 +1381,20 @@ slab_out_of_memory(struct kmem_cache *ca
 		cachep->name, cachep->size, cachep->gfporder);
 
 	for_each_kmem_cache_node(cachep, node, n) {
-		unsigned long active_objs = 0, num_objs = 0, free_objects = 0;
-		unsigned long active_slabs = 0, num_slabs = 0;
-		unsigned long num_slabs_partial = 0, num_slabs_free = 0;
-		unsigned long num_slabs_full;
+		unsigned long active_objs = 0, free_objs = 0;
+		unsigned long active_slabs, num_slabs;
 
 		spin_lock_irqsave(&n->list_lock, flags);
-		num_slabs = n->num_slabs;
-		list_for_each_entry(page, &n->slabs_partial, lru) {
-			active_objs += page->active;
-			num_slabs_partial++;
-		}
-		list_for_each_entry(page, &n->slabs_free, lru)
-			num_slabs_free++;
+		active_slabs = n->active_slabs;
+		num_slabs = active_slabs + n->free_slabs;
 
-		free_objects += n->free_objects;
+		active_objs += (num_slabs * cachep->num) - n->free_objects;
+		free_objs += n->free_objects;
 		spin_unlock_irqrestore(&n->list_lock, flags);
 
-		num_objs = num_slabs * cachep->num;
-		active_slabs = num_slabs - num_slabs_free;
-		num_slabs_full = num_slabs -
-			(num_slabs_partial + num_slabs_free);
-		active_objs += (num_slabs_full * cachep->num);
-
 		pr_warn("  node %d: slabs: %ld/%ld, objs: %ld/%ld, free: %ld\n",
-			node, active_slabs, num_slabs, active_objs, num_objs,
-			free_objects);
+			node, active_slabs, num_slabs, active_objs,
+			num_slabs * cachep->num, free_objs);
 	}
 #endif
 }
@@ -2318,7 +2306,7 @@ static int drain_freelist(struct kmem_ca
 
 		page = list_entry(p, struct page, lru);
 		list_del(&page->lru);
-		n->num_slabs--;
+		n->free_slabs--;
 		/*
 		 * Safe to drop the lock. The slab is no longer linked
 		 * to the cache.
@@ -2753,12 +2741,14 @@ static void cache_grow_end(struct kmem_c
 	n = get_node(cachep, page_to_nid(page));
 
 	spin_lock(&n->list_lock);
-	if (!page->active)
+	if (!page->active) {
 		list_add_tail(&page->lru, &(n->slabs_free));
-	else
+		n->free_slabs++;
+	} else {
 		fixup_slab_list(cachep, n, page, &list);
+		n->active_slabs++;
+	}
 
-	n->num_slabs++;
 	STATS_INC_GROWN(cachep);
 	n->free_objects += cachep->num - page->active;
 	spin_unlock(&n->list_lock);
@@ -2884,7 +2874,7 @@ static inline void fixup_slab_list(struc
 
 /* Try to find non-pfmemalloc slab if needed */
 static noinline struct page *get_valid_first_slab(struct kmem_cache_node *n,
-					struct page *page, bool pfmemalloc)
+			struct page *page, bool *page_is_free, bool pfmemalloc)
 {
 	if (!page)
 		return NULL;
@@ -2903,9 +2893,11 @@ static noinline struct page *get_valid_f
 
 	/* Move pfmemalloc slab to the end of list to speed up next search */
 	list_del(&page->lru);
-	if (!page->active)
+	if (*page_is_free) {
+		WARN_ON(page->active);
 		list_add_tail(&page->lru, &n->slabs_free);
-	else
+		*page_is_free = false;
+	} else
 		list_add_tail(&page->lru, &n->slabs_partial);
 
 	list_for_each_entry(page, &n->slabs_partial, lru) {
@@ -2913,9 +2905,12 @@ static noinline struct page *get_valid_f
 			return page;
 	}
 
+	n->free_touched = 1;
 	list_for_each_entry(page, &n->slabs_free, lru) {
-		if (!PageSlabPfmemalloc(page))
+		if (!PageSlabPfmemalloc(page)) {
+			*page_is_free = true;
 			return page;
+		}
 	}
 
 	return NULL;
@@ -2924,17 +2919,26 @@ static noinline struct page *get_valid_f
 static struct page *get_first_slab(struct kmem_cache_node *n, bool pfmemalloc)
 {
 	struct page *page;
+	bool page_is_free = false;
 
+	assert_spin_locked(&n->list_lock);
 	page = list_first_entry_or_null(&n->slabs_partial,
 			struct page, lru);
 	if (!page) {
 		n->free_touched = 1;
 		page = list_first_entry_or_null(&n->slabs_free,
 				struct page, lru);
+		if (page)
+			page_is_free = true;
 	}
 
 	if (sk_memalloc_socks())
-		return get_valid_first_slab(n, page, pfmemalloc);
+		page = get_valid_first_slab(n, page, &page_is_free, pfmemalloc);
+
+	if (page && page_is_free) {
+		n->active_slabs++;
+		n->free_slabs--;
+	}
 
 	return page;
 }
@@ -3434,9 +3438,11 @@ static void free_block(struct kmem_cache
 		STATS_DEC_ACTIVE(cachep);
 
 		/* fixup slab chains */
-		if (page->active == 0)
+		if (page->active == 0) {
 			list_add(&page->lru, &n->slabs_free);
-		else {
+			n->free_slabs++;
+			n->active_slabs--;
+		} else {
 			/* Unconditionally move a slab to the end of the
 			 * partial list on free - maximum time for the
 			 * other objects to be freed, too.
@@ -3450,7 +3456,7 @@ static void free_block(struct kmem_cache
 
 		page = list_last_entry(&n->slabs_free, struct page, lru);
 		list_move(&page->lru, list);
-		n->num_slabs--;
+		n->free_slabs--;
 	}
 }
 
@@ -4102,43 +4108,21 @@ out:
 #ifdef CONFIG_SLABINFO
 void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo)
 {
-	struct page *page;
-	unsigned long active_objs;
-	unsigned long num_objs;
-	unsigned long active_slabs = 0;
-	unsigned long num_slabs, free_objects = 0, shared_avail = 0;
-	unsigned long num_slabs_partial = 0, num_slabs_free = 0;
-	unsigned long num_slabs_full = 0;
-	const char *name;
-	char *error = NULL;
+	unsigned long active_objs, num_objs, active_slabs;
+	unsigned long num_slabs = 0, free_objs = 0, shared_avail = 0;
+	unsigned long num_slabs_free = 0;
 	int node;
 	struct kmem_cache_node *n;
 
-	active_objs = 0;
-	num_slabs = 0;
 	for_each_kmem_cache_node(cachep, node, n) {
-
 		check_irq_on();
 		spin_lock_irq(&n->list_lock);
 
-		num_slabs += n->num_slabs;
+		num_slabs += n->active_slabs + n->free_slabs;
+		num_slabs_free += n->free_slabs;
 
-		list_for_each_entry(page, &n->slabs_partial, lru) {
-			if (page->active == cachep->num && !error)
-				error = "slabs_partial accounting error";
-			if (!page->active && !error)
-				error = "slabs_partial accounting error";
-			active_objs += page->active;
-			num_slabs_partial++;
-		}
+		free_objs += n->free_objects;
 
-		list_for_each_entry(page, &n->slabs_free, lru) {
-			if (page->active && !error)
-				error = "slabs_free accounting error";
-			num_slabs_free++;
-		}
-
-		free_objects += n->free_objects;
 		if (n->shared)
 			shared_avail += n->shared->avail;
 
@@ -4146,15 +4130,8 @@ void get_slabinfo(struct kmem_cache *cac
 	}
 	num_objs = num_slabs * cachep->num;
 	active_slabs = num_slabs - num_slabs_free;
-	num_slabs_full = num_slabs - (num_slabs_partial + num_slabs_free);
-	active_objs += (num_slabs_full * cachep->num);
-
-	if (num_objs - active_objs != free_objects && !error)
-		error = "free_objects accounting error";
 
-	name = cachep->name;
-	if (error)
-		pr_err("slab: cache %s error: %s\n", name, error);
+	active_objs = num_objs - free_objs;
 
 	sinfo->active_objs = active_objs;
 	sinfo->num_objs = num_objs;
diff -puN mm/slab.h~mm-slab-faster-active-and-free-stats mm/slab.h
--- a/mm/slab.h~mm-slab-faster-active-and-free-stats
+++ a/mm/slab.h
@@ -447,7 +447,8 @@ struct kmem_cache_node {
 	struct list_head slabs_partial;	/* partial list first, better asm code */
 	struct list_head slabs_full;
 	struct list_head slabs_free;
-	unsigned long num_slabs;
+	unsigned long active_slabs;	/* length of slabs_partial+slabs_full */
+	unsigned long free_slabs;	/* length of slabs_free */
 	unsigned long free_objects;
 	unsigned int free_limit;
 	unsigned int colour_next;	/* Per-node cache coloring */
_

Patches currently in -mm which might be from gthelen@google.com are

memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab.patch
mm-slab-faster-active-and-free-stats.patch


^ permalink raw reply

* Re: [PATCH 0/11 v2] ext4: Convert ext4 DAX IO to iomap framework
From: Dave Chinner @ 2016-11-08 23:17 UTC (permalink / raw)
  To: Jan Kara
  Cc: Ted Tso, linux-ext4, linux-fsdevel, Christoph Hellwig,
	Ross Zwisler
In-Reply-To: <1478603297-11793-1-git-send-email-jack@suse.cz>

On Tue, Nov 08, 2016 at 12:08:06PM +0100, Jan Kara wrote:
> Hello,
> 
> this is a second revision of my patches to convert ext4 DAX IO paths to the new
> iomap framework and removes the old bh-based DAX functions. As a result ext4
> gains PMD page fault support, also some other minor bugs get fixed. The patch
> set is based on Ross' DAX PMD page fault support series [1]. It passes xfstests
> both in DAX and non-DAX mode.
> 
> I have pushed out updated version of these patches including the follow-up
> DAX patches to:
> 
> git://get.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git dax
> 
> for easy testing. Once Dave pushes out a stable branch with Ross' patches, we
> pull those into ext4 tree and then pull these patches on top of that (provided
> nobody will have other objections to the current series).

Done:

git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git dax-4.10-iomap-pmd

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply

* Re: [patch] mm, slab: faster active and free stats
From: Andrew Morton @ 2016-11-08 23:17 UTC (permalink / raw)
  To: David Rientjes
  Cc: Greg Thelen, Aruna Ramakrishna, Christoph Lameter, Joonsoo Kim,
	linux-kernel, linux-mm
In-Reply-To: <alpine.DEB.2.10.1611081505240.13403@chino.kir.corp.google.com>

On Tue, 8 Nov 2016 15:06:45 -0800 (PST) David Rientjes <rientjes@google.com> wrote:

> Reading /proc/slabinfo or monitoring slabtop(1) can become very expensive
> if there are many slab caches and if there are very lengthy per-node
> partial and/or free lists.
> 
> Commit 07a63c41fa1f ("mm/slab: improve performance of gathering slabinfo
> stats") addressed the per-node full lists which showed a significant
> improvement when no objects were freed.  This patch has the same
> motivation and optimizes the remainder of the usecases where there are
> very lengthy partial and free lists.
> 
> This patch maintains per-node active_slabs (full and partial) and
> free_slabs rather than iterating the lists at runtime when reading
> /proc/slabinfo.

Are there any nice numbers you can share?

^ permalink raw reply

* Re: [patch] mm, slab: faster active and free stats
From: Andrew Morton @ 2016-11-08 23:17 UTC (permalink / raw)
  To: David Rientjes
  Cc: Greg Thelen, Aruna Ramakrishna, Christoph Lameter, Joonsoo Kim,
	linux-kernel, linux-mm
In-Reply-To: <alpine.DEB.2.10.1611081505240.13403@chino.kir.corp.google.com>

On Tue, 8 Nov 2016 15:06:45 -0800 (PST) David Rientjes <rientjes@google.com> wrote:

> Reading /proc/slabinfo or monitoring slabtop(1) can become very expensive
> if there are many slab caches and if there are very lengthy per-node
> partial and/or free lists.
> 
> Commit 07a63c41fa1f ("mm/slab: improve performance of gathering slabinfo
> stats") addressed the per-node full lists which showed a significant
> improvement when no objects were freed.  This patch has the same
> motivation and optimizes the remainder of the usecases where there are
> very lengthy partial and free lists.
> 
> This patch maintains per-node active_slabs (full and partial) and
> free_slabs rather than iterating the lists at runtime when reading
> /proc/slabinfo.

Are there any nice numbers you can share?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* [U-Boot] [linux-sunxi] [PATCH 2/3] net: phy: realtek: make define more concistent
From: Emilio López @ 2016-11-08 23:17 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20161108163859.14760-3-oliver@schinagl.nl>

Small nitpick:

El 08/11/16 a las 13:38, Olliver Schinagl escribi?:
> All internal defines in the realtek phy are with a small X,
> except MIIM_RTL8211X_CTRL1000T_MASTER. Make this more concistent

s/concistent/consistent/ both here and on the subject :)

Cheers!
Emilio

^ permalink raw reply

* Re: [PATCH] kvm: x86: remove unused but set variable
From: Paolo Bonzini @ 2016-11-08 23:17 UTC (permalink / raw)
  To: Jiang Biao, kvm; +Cc: rkrcmar, zhong.weidong
In-Reply-To: <1478480236-26038-1-git-send-email-jiang.biao2@zte.com.cn>



On 07/11/2016 01:57, Jiang Biao wrote:
> The local variable *gpa_offset* is set but not used afterwards,
> which make the compiler issue a warning with option
> -Wunused-but-set-variable. Remove it to avoid the warning.
> 
> Signed-off-by: Jiang Biao <jiang.biao2@zte.com.cn>
> ---
>  arch/x86/kvm/x86.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index cfd916c..a55d024 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2162,7 +2162,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  		break;
>  	case MSR_KVM_SYSTEM_TIME_NEW:
>  	case MSR_KVM_SYSTEM_TIME: {
> -		u64 gpa_offset;
>  		struct kvm_arch *ka = &vcpu->kvm->arch;
>  
>  		kvmclock_reset(vcpu);
> @@ -2184,8 +2183,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  		if (!(data & 1))
>  			break;
>  
> -		gpa_offset = data & ~(PAGE_MASK | 1);
> -
>  		if (kvm_gfn_to_hva_cache_init(vcpu->kvm,
>  		     &vcpu->arch.pv_time, data & ~1ULL,
>  		     sizeof(struct pvclock_vcpu_time_info)))
> 

Applied all four, thanks.

Paolo

^ permalink raw reply

* Re: Could receive allow updating an existing subvolume?
From: Ian Kelling @ 2016-11-08 23:17 UTC (permalink / raw)
  To: Hugo Mills; +Cc: linux-btrfs
In-Reply-To: <1478646934.2753701.781728689.373545C7@webmail.messagingengine.com>



On Tue, Nov 8, 2016, at 03:15 PM, Ian Kelling wrote:
> On Tue, Nov 8, 2016, at 03:00 PM, Hugo Mills wrote:
> > 
> >    If the sender sends an incremental stream, that assumes an *exact*
> > subvol state on the receiving side. If the subvol on the receiving
> > side is modified, then the receive can fail.
> 
> No. The reading program never needs to have access to rw files if it's
> reading from a read-only mountpoint while the subvolume is rw and
> mounted as such elsewhere. And a reading program does not magically risk
> writes.

Quoted text was accidentally duplicated, ignore it.

^ permalink raw reply

* [ANNOUNCE] xfs: for-next branch updated to 84716639acc3
From: Dave Chinner @ 2016-11-08 23:16 UTC (permalink / raw)
  To: linux-xfs; +Cc: linux-fsdevel, jack, tytso, ross.zwisler

Hi folks,

The for-next branch of the xfs kernel repository at

git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git

has just been updated.

This update includes the DAX iomap PMD fault infrastructure, a bunch
of libxfs cleanups that sync the kernel code with changes that
have been made in the userspace libxfs and a few bug fixes thrown in
there for good measure.

Jan, Ted and Ross:

I have pushed the DAX changes into a stable topic branch named
"dax-4.10-iomap-pmd".  Any fixes to this code will be appended to
this branch - the commits are now stable so that it can be pulled
into other trees for further development of DAX features for this
cycle.

The dax-4.10-iomap-pmd branch will also reach linux-next via the
merge into the for-next branch. However, keep in mind that the 
for-next in the XFS tree is not a stable branch - it may get
rebased from time to time as stable topic branches have commits
appended - so treat the for-next branch like you treat linux-next.

-Dave.

The new head of the for-next branch is commit:

84716639acc3 Merge branch 'xfs-4.10-misc-fixes-1' into for-next

New Commits:

Brian Foster (2):
      [399372349a7f] xfs: don't skip cow forks w/ delalloc blocks in cowblocks scan
      [04197b341f23] xfs: don't BUG() on mixed direct and mapped I/O

Darrick J. Wong (8):
      [755c7bf5ddca] libxfs: convert ushort to unsigned short
      [420fbeb4bff4] libxfs: synchronize dinode_verify with userspace
      [68c098582b20] libxfs: fix whitespace problems
      [ae90b994b40f] libxfs: fix xfs_attr_shortform_bytesfit declaration
      [523b2e76e3ec] libxfs: clean up _dir2_data_freescan
      [5e52365ac863] xfs: move dir_ino_validate declaration per xfsprogs
      [4fd29ec47212] xfs: check return value of _trans_reserve_quota_nblks
      [132f2ac5055a] xfs: check minimum block size for CRC filesystems

Dave Chinner (3):
      [e823656675ac] Merge branch 'dax-4.10-iomap-pmd' into for-next
      [baa5baeb87de] Merge branch 'xfs-4.10-libxfs-cleanups' into for-next
      [84716639acc3] Merge branch 'xfs-4.10-misc-fixes-1' into for-next

Eric Sandeen (3):
      [e6fc6fcf4447] xfs: don't call xfs_sb_quota_from_disk twice
      [4dfce57db635] xfs: fix up xfs_swap_extent_forks inline extent handling
      [5d829300bee0] xfs: provide helper for counting extents from if_bytes

Ross Zwisler (16):
      [547edce3ba23] ext4: tell DAX the size of allocation holes
      [fa0d3fce7cef] dax: remove buffer_size_valid()
      [03e0990fc88f] ext2: remove support for DAX PMD faults
      [ce95ab0fa669] dax: make 'wait_table' global variable static
      [aada54f98004] dax: remove the last BUG_ON() from fs/dax.c
      [e3ad61c64abc] dax: consistent variable naming for DAX entries
      [63e95b5c4f16] dax: coordinate locking for offsets in PMD range
      [b9fde0462e34] dax: remove dax_pmd_fault()
      [11c59c92f44d] dax: correct dax iomap code namespace
      [333ccc978e1e] dax: add dax_iomap_sector() helper function
      [1550290b0801] dax: dax_iomap_fault() needs to call iomap_end()
      [fa28f7296a7c] dax: move RADIX_DAX_* defines to dax.h
      [422476c4641e] dax: move put_(un)locked_mapping_entry() in dax.c
      [642261ac995e] dax: add struct iomap based DAX PMD support
      [862f1b9d6718] xfs: use struct iomap based DAX PMD fault path
      [190b5caad750] dax: remove "depends on BROKEN" from FS_DAX_PMD


Code Diffstat:

 fs/Kconfig                      |   1 -
 fs/dax.c                        | 826 ++++++++++++++++++++++++-------------------
 fs/ext2/file.c                  |  35 +-
 fs/ext4/inode.c                 |   3 +
 fs/xfs/libxfs/xfs_attr_leaf.h   |   2 +-
 fs/xfs/libxfs/xfs_bmap.c        |  54 +--
 fs/xfs/libxfs/xfs_dir2.h        |   5 +
 fs/xfs/libxfs/xfs_dir2_data.c   |  24 +-
 fs/xfs/libxfs/xfs_dir2_priv.h   |   1 -
 fs/xfs/libxfs/xfs_ialloc.c      |   5 +-
 fs/xfs/libxfs/xfs_inode_buf.c   |   6 +-
 fs/xfs/libxfs/xfs_inode_buf.h   |   4 +-
 fs/xfs/libxfs/xfs_inode_fork.c  |  31 +-
 fs/xfs/libxfs/xfs_inode_fork.h  |   1 +
 fs/xfs/libxfs/xfs_log_format.h  |   4 +-
 fs/xfs/libxfs/xfs_log_recover.h |   2 +-
 fs/xfs/libxfs/xfs_rtbitmap.c    |   1 -
 fs/xfs/libxfs/xfs_sb.c          |  14 +-
 fs/xfs/libxfs/xfs_types.h       |   3 +
 fs/xfs/xfs_aops.c               |  48 +--
 fs/xfs/xfs_aops.h               |   3 -
 fs/xfs/xfs_bmap_util.c          |  33 +-
 fs/xfs/xfs_file.c               |  10 +-
 fs/xfs/xfs_icache.c             |   7 +-
 fs/xfs/xfs_inode_item.c         |   4 +-
 fs/xfs/xfs_ioctl.c              |   6 +-
 fs/xfs/xfs_log_recover.c        |   4 +-
 fs/xfs/xfs_qm.c                 |   2 +-
 fs/xfs/xfs_reflink.c            |  38 +-
 fs/xfs/xfs_reflink.h            |   2 -
 include/linux/dax.h             |  58 ++-
 mm/filemap.c                    |   5 +-
 32 files changed, 683 insertions(+), 559 deletions(-)
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply

* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Benjamin Herrenschmidt @ 2016-11-08 23:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161108120323.GC15297@leverpostej>

On Tue, 2016-11-08 at 12:03 +0000, Mark Rutland wrote:
> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> > 
> > For arm64, there is no I/O space as other architectural platforms, such as
> > X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
> > such as Hip06, when accessing some legacy ISA devices connected to LPC, those
> > known port addresses are used to control the corresponding target devices, for
> > example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
> > normal MMIO mode in using.
> 
> This has nothing to do with arm64. Hardware with this kind of indirect
> bus access could be integrated with a variety of CPU architectures. It
> simply hasn't been, yet.

On some ppc's we also use similar indirect access methods for IOs. We
have a generic infrastructure for re-routing some memory or IO regions
to hooks.

On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
firmware calls ;-) We use that infrastructure to plumb in the LPC bus.

> > To drive these devices, this patch introduces a method named indirect-IO.
> > In this method the in/out pair in arch/arm64/include/asm/io.h will be
> > redefined. When upper layer drivers call in/out with those known legacy port
> > addresses to access the peripherals, the hooking functions corrresponding to
> > those target peripherals will be called. Through this way, those upper layer
> > drivers which depend on in/out can run on Hip06 without any changes.
> 
> As above, this has nothing to do with arm64, and as such, should live in
> generic code, exactly as we would do if we had higher-level ISA
> accessor ops.
> 
> Regardless, given the multi-instance case, I don't think this is
> sufficient in general (and I think we need higher-level ISA accessors
> to handle the indirection).

Multi-instance with IO is tricky to do generically because archs already
have all sort of hacks to deal with the fact that inb/outb don't require
an explicit ioremap, so an IO resource can take all sort of shape depending
on the arch.

Overall it boils down to applying some kind of per-instance "offset" to
the IO port number though.

> [...]
> 
> > 
> > diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
> > new file mode 100644
> > index 0000000..6ae0787
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/extio.h
> 
> > 
> > +#ifndef __LINUX_EXTIO_H
> > +#define __LINUX_EXTIO_H
> 
> This doesn't match the file naming, __ASM_EXTIO_H would be consistent
> with other arm64 headers.
> 
> > 
> > +
> > +struct extio_ops {
> > > > +	unsigned long start;/* inclusive, sys io addr */
> > > > +	unsigned long end;/* inclusive, sys io addr */
> 
> Please put whitespace before inline comments.
> 
> [...]
> 
> > 
> > > > +type in##bw(unsigned long addr)						\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		return read##bw(PCI_IOBASE + addr);			\
> > > > > > +	return arm64_extio_ops->pfin ?					\
> > > > > > +		arm64_extio_ops->pfin(arm64_extio_ops->devpara,		\
> > > > > > +			addr, sizeof(type)) : -1;			\
> > > > +}									\
> > > > +									\
> > > > +void out##bw(type value, unsigned long addr)				\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		write##bw(value, PCI_IOBASE + addr);			\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfout)				\
> > > > +			arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> > > > > > +				addr, value, sizeof(type));		\
> > > > +}									\
> > > > +									\
> > > > +void ins##bw(unsigned long addr, void *buffer, unsigned int count)	\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		reads##bw(PCI_IOBASE + addr, buffer, count);		\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfins)				\
> > > > +			arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
> > > > > > +				addr, buffer, sizeof(type), count);	\
> > > > +}									\
> > > > +									\
> > > > +void outs##bw(unsigned long addr, const void *buffer, unsigned int count)	\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		writes##bw(PCI_IOBASE + addr, buffer, count);		\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfouts)				\
> > > > +			arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
> > > > > > +				addr, buffer, sizeof(type), count);	\
> > +}
> > +
> 
> So all PCI I/O will be slowed down by irrelevant checks when this is
> enabled?
> 
> [...]
> 
> > 
> > +static inline void arm64_set_extops(struct extio_ops *ops)
> > +{
> > > > +	if (ops)
> > > > +		WRITE_ONCE(arm64_extio_ops, ops);
> > +}
> 
> Why WRITE_ONCE()?
> 
> Is this not protected/propagated by some synchronisation mechanism?
> 
> WRITE_ONCE() is not sufficient to ensure that this is consistently
> observed by readers, and regardless, I don't see READ_ONCE() anywhere in
> this patch.
> 
> This looks very suspicious.
> 
> Thanks,
> Mark.

^ permalink raw reply

* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Benjamin Herrenschmidt @ 2016-11-08 23:16 UTC (permalink / raw)
  To: Mark Rutland, zhichang.yuan
  Cc: catalin.marinas, will.deacon, robh+dt, bhelgaas, olof, arnd,
	linux-arm-kernel, lorenzo.pieralisi, linux-kernel, linuxarm,
	devicetree, linux-pci, linux-serial, minyard, liviu.dudau,
	zourongrong, john.garry, gabriele.paoloni, zhichang.yuan02,
	kantyzc, xuwei5, marc.zyngier
In-Reply-To: <20161108120323.GC15297@leverpostej>

On Tue, 2016-11-08 at 12:03 +0000, Mark Rutland wrote:
> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> > 
> > For arm64, there is no I/O space as other architectural platforms, such as
> > X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
> > such as Hip06, when accessing some legacy ISA devices connected to LPC, those
> > known port addresses are used to control the corresponding target devices, for
> > example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
> > normal MMIO mode in using.
> 
> This has nothing to do with arm64. Hardware with this kind of indirect
> bus access could be integrated with a variety of CPU architectures. It
> simply hasn't been, yet.

On some ppc's we also use similar indirect access methods for IOs. We
have a generic infrastructure for re-routing some memory or IO regions
to hooks.

On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
firmware calls ;-) We use that infrastructure to plumb in the LPC bus.

> > To drive these devices, this patch introduces a method named indirect-IO.
> > In this method the in/out pair in arch/arm64/include/asm/io.h will be
> > redefined. When upper layer drivers call in/out with those known legacy port
> > addresses to access the peripherals, the hooking functions corrresponding to
> > those target peripherals will be called. Through this way, those upper layer
> > drivers which depend on in/out can run on Hip06 without any changes.
> 
> As above, this has nothing to do with arm64, and as such, should live in
> generic code, exactly as we would do if we had higher-level ISA
> accessor ops.
> 
> Regardless, given the multi-instance case, I don't think this is
> sufficient in general (and I think we need higher-level ISA accessors
> to handle the indirection).

Multi-instance with IO is tricky to do generically because archs already
have all sort of hacks to deal with the fact that inb/outb don't require
an explicit ioremap, so an IO resource can take all sort of shape depending
on the arch.

Overall it boils down to applying some kind of per-instance "offset" to
the IO port number though.

> [...]
> 
> > 
> > diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
> > new file mode 100644
> > index 0000000..6ae0787
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/extio.h
> 
> > 
> > +#ifndef __LINUX_EXTIO_H
> > +#define __LINUX_EXTIO_H
> 
> This doesn't match the file naming, __ASM_EXTIO_H would be consistent
> with other arm64 headers.
> 
> > 
> > +
> > +struct extio_ops {
> > > > +	unsigned long start;/* inclusive, sys io addr */
> > > > +	unsigned long end;/* inclusive, sys io addr */
> 
> Please put whitespace before inline comments.
> 
> [...]
> 
> > 
> > > > +type in##bw(unsigned long addr)						\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		return read##bw(PCI_IOBASE + addr);			\
> > > > > > +	return arm64_extio_ops->pfin ?					\
> > > > > > +		arm64_extio_ops->pfin(arm64_extio_ops->devpara,		\
> > > > > > +			addr, sizeof(type)) : -1;			\
> > > > +}									\
> > > > +									\
> > > > +void out##bw(type value, unsigned long addr)				\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		write##bw(value, PCI_IOBASE + addr);			\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfout)				\
> > > > +			arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> > > > > > +				addr, value, sizeof(type));		\
> > > > +}									\
> > > > +									\
> > > > +void ins##bw(unsigned long addr, void *buffer, unsigned int count)	\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		reads##bw(PCI_IOBASE + addr, buffer, count);		\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfins)				\
> > > > +			arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
> > > > > > +				addr, buffer, sizeof(type), count);	\
> > > > +}									\
> > > > +									\
> > > > +void outs##bw(unsigned long addr, const void *buffer, unsigned int count)	\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		writes##bw(PCI_IOBASE + addr, buffer, count);		\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfouts)				\
> > > > +			arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
> > > > > > +				addr, buffer, sizeof(type), count);	\
> > +}
> > +
> 
> So all PCI I/O will be slowed down by irrelevant checks when this is
> enabled?
> 
> [...]
> 
> > 
> > +static inline void arm64_set_extops(struct extio_ops *ops)
> > +{
> > > > +	if (ops)
> > > > +		WRITE_ONCE(arm64_extio_ops, ops);
> > +}
> 
> Why WRITE_ONCE()?
> 
> Is this not protected/propagated by some synchronisation mechanism?
> 
> WRITE_ONCE() is not sufficient to ensure that this is consistently
> observed by readers, and regardless, I don't see READ_ONCE() anywhere in
> this patch.
> 
> This looks very suspicious.
> 
> Thanks,
> Mark.

^ permalink raw reply

* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Benjamin Herrenschmidt @ 2016-11-08 23:16 UTC (permalink / raw)
  To: Mark Rutland, zhichang.yuan
  Cc: gabriele.paoloni, catalin.marinas, will.deacon, linuxarm,
	lorenzo.pieralisi, arnd, xuwei5, linux-serial, linux-pci,
	devicetree, minyard, marc.zyngier, liviu.dudau, john.garry,
	zourongrong, robh+dt, bhelgaas, kantyzc, zhichang.yuan02,
	linux-arm-kernel, linux-kernel, olof
In-Reply-To: <20161108120323.GC15297@leverpostej>

On Tue, 2016-11-08 at 12:03 +0000, Mark Rutland wrote:
> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> > 
> > For arm64, there is no I/O space as other architectural platforms, such as
> > X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
> > such as Hip06, when accessing some legacy ISA devices connected to LPC, those
> > known port addresses are used to control the corresponding target devices, for
> > example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
> > normal MMIO mode in using.
> 
> This has nothing to do with arm64. Hardware with this kind of indirect
> bus access could be integrated with a variety of CPU architectures. It
> simply hasn't been, yet.

On some ppc's we also use similar indirect access methods for IOs. We
have a generic infrastructure for re-routing some memory or IO regions
to hooks.

On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
firmware calls ;-) We use that infrastructure to plumb in the LPC bus.

> > To drive these devices, this patch introduces a method named indirect-IO.
> > In this method the in/out pair in arch/arm64/include/asm/io.h will be
> > redefined. When upper layer drivers call in/out with those known legacy port
> > addresses to access the peripherals, the hooking functions corrresponding to
> > those target peripherals will be called. Through this way, those upper layer
> > drivers which depend on in/out can run on Hip06 without any changes.
> 
> As above, this has nothing to do with arm64, and as such, should live in
> generic code, exactly as we would do if we had higher-level ISA
> accessor ops.
> 
> Regardless, given the multi-instance case, I don't think this is
> sufficient in general (and I think we need higher-level ISA accessors
> to handle the indirection).

Multi-instance with IO is tricky to do generically because archs already
have all sort of hacks to deal with the fact that inb/outb don't require
an explicit ioremap, so an IO resource can take all sort of shape depending
on the arch.

Overall it boils down to applying some kind of per-instance "offset" to
the IO port number though.

> [...]
> 
> > 
> > diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
> > new file mode 100644
> > index 0000000..6ae0787
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/extio.h
> 
> > 
> > +#ifndef __LINUX_EXTIO_H
> > +#define __LINUX_EXTIO_H
> 
> This doesn't match the file naming, __ASM_EXTIO_H would be consistent
> with other arm64 headers.
> 
> > 
> > +
> > +struct extio_ops {
> > > > +	unsigned long start;/* inclusive, sys io addr */
> > > > +	unsigned long end;/* inclusive, sys io addr */
> 
> Please put whitespace before inline comments.
> 
> [...]
> 
> > 
> > > > +type in##bw(unsigned long addr)						\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		return read##bw(PCI_IOBASE + addr);			\
> > > > > > +	return arm64_extio_ops->pfin ?					\
> > > > > > +		arm64_extio_ops->pfin(arm64_extio_ops->devpara,		\
> > > > > > +			addr, sizeof(type)) : -1;			\
> > > > +}									\
> > > > +									\
> > > > +void out##bw(type value, unsigned long addr)				\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		write##bw(value, PCI_IOBASE + addr);			\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfout)				\
> > > > +			arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> > > > > > +				addr, value, sizeof(type));		\
> > > > +}									\
> > > > +									\
> > > > +void ins##bw(unsigned long addr, void *buffer, unsigned int count)	\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		reads##bw(PCI_IOBASE + addr, buffer, count);		\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfins)				\
> > > > +			arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
> > > > > > +				addr, buffer, sizeof(type), count);	\
> > > > +}									\
> > > > +									\
> > > > +void outs##bw(unsigned long addr, const void *buffer, unsigned int count)	\
> > > > +{									\
> > > > > > +	if (!arm64_extio_ops || arm64_extio_ops->start > addr ||	\
> > > > > > +			arm64_extio_ops->end < addr)			\
> > > > > > +		writes##bw(PCI_IOBASE + addr, buffer, count);		\
> > > > > > +	else								\
> > > > > > +		if (arm64_extio_ops->pfouts)				\
> > > > +			arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
> > > > > > +				addr, buffer, sizeof(type), count);	\
> > +}
> > +
> 
> So all PCI I/O will be slowed down by irrelevant checks when this is
> enabled?
> 
> [...]
> 
> > 
> > +static inline void arm64_set_extops(struct extio_ops *ops)
> > +{
> > > > +	if (ops)
> > > > +		WRITE_ONCE(arm64_extio_ops, ops);
> > +}
> 
> Why WRITE_ONCE()?
> 
> Is this not protected/propagated by some synchronisation mechanism?
> 
> WRITE_ONCE() is not sufficient to ensure that this is consistently
> observed by readers, and regardless, I don't see READ_ONCE() anywhere in
> this patch.
> 
> This looks very suspicious.
> 
> Thanks,
> Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v7 02/17] ref-filter: include reference to 'used_atom' within 'atom_value'
From: Jacob Keller @ 2016-11-08 23:16 UTC (permalink / raw)
  To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-3-Karthik.188@gmail.com>

On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> Ensure that each 'atom_value' has a reference to its corresponding
> 'used_atom'. This let's us use values within 'used_atom' in the
> 'handler' function.
>
> Hence we can get the %(align) atom's parameters directly from the
> 'used_atom' therefore removing the necessity of passing %(align) atom's
> parameters to 'atom_value'.
>
> This also acts as a preparatory patch for the upcoming patch where we
> introduce %(if:equals=) and %(if:notequals=).
>

Makes sense.

> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
> ---
>  ref-filter.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/ref-filter.c b/ref-filter.c
> index 8c183a0..8392303 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -230,11 +230,9 @@ struct ref_formatting_state {
>
>  struct atom_value {
>         const char *s;
> -       union {
> -               struct align align;
> -       } u;
>         void (*handler)(struct atom_value *atomv, struct ref_formatting_state *state);
>         unsigned long ul; /* used for sorting when not FIELD_STR */
> +       struct used_atom *atom;
>  };
>
>  /*
> @@ -370,7 +368,7 @@ static void align_atom_handler(struct atom_value *atomv, struct ref_formatting_s
>         push_stack_element(&state->stack);
>         new = state->stack;
>         new->at_end = end_align_handler;
> -       new->at_end_data = &atomv->u.align;
> +       new->at_end_data = &atomv->atom->u.align;

At first, this confused me. I was like "we dropped the union, why are
we still referencing it. But I realized that the "used_atom" struct
actually contains the same union and we were copying it.

Ok, so this looks good.

Thanks,
Jake

>  }
>
>  static void if_then_else_handler(struct ref_formatting_stack **stack)
> @@ -1069,6 +1067,7 @@ static void populate_value(struct ref_array_item *ref)
>                 struct branch *branch = NULL;
>
>                 v->handler = append_atom;
> +               v->atom = atom;
>
>                 if (*name == '*') {
>                         deref = 1;
> @@ -1133,7 +1132,6 @@ static void populate_value(struct ref_array_item *ref)
>                                 v->s = " ";
>                         continue;
>                 } else if (starts_with(name, "align")) {
> -                       v->u.align = atom->u.align;
>                         v->handler = align_atom_handler;
>                         continue;
>                 } else if (!strcmp(name, "end")) {
> --
> 2.10.2
>

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.