[PATCH] ACPI: Update the maximum depth of C-state from 6 to 9
From: Chuansheng Liu Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file, and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of C-state. This change is reflected in one place of the kernel-param file, but not in the other place where I suggest changing. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 82b42c9..a863737 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1661,7 +1661,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. intel_idle.max_cstate= [KNL,HW,ACPI,X86] 0 disables intel_idle and fall back on acpi_idle. - 1 to 6 specify maximum depth of C-state. + 1 to 9 specify maximum depth of C-state. intel_pstate= [X86] disable -- 2.8.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
On Sun 2016-07-03 15:08:07, Topi Miettinen wrote: > The attached patch would make any uses of capabilities generate audit > messages. It works for simple tests as you can see from the commit > message, but unfortunately the call to audit_cgroup_list() deadlocks the > system when booting a full blown OS. There's no deadlock when the call > is removed. > > I guess that in some cases, cgroup_mutex and/or css_set_lock could be > already held earlier before entering audit_cgroup_list(). Holding the > locks is however required by task_cgroup_from_root(). Is there any way > to avoid this? For example, only print some kind of cgroup ID numbers > (are there unique and stable IDs, available without locks?) for those > cgroups where the task is registered in the audit message? I am not sure if anyone know what really happens here. I suggest to enable lockdep. It might detect possible deadlock even before it really happens, see Documentation/locking/lockdep-design.txt It can be enabled by CONFIG_PROVE_LOCKING=y It depends on CONFIG_DEBUG_KERNEL=y and maybe some more options, see lib/Kconfig.debug Best Regards, Petr -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] Doc/memory-barriers: Add Korean translation
On Mon, Jul 04, 2016 at 08:27:08AM +0900, SeongJae Park wrote:
> +===
> +이 문서는
> +Documentation/memory-barriers.txt
> +의 한글 번역입니다.
> +
> +역자： 박성재
> +===
> +
> +
> + =
> + 리눅스 커널 메모리 배리어
> + =
> +
> +저자: David Howells
> + Paul E. McKenney
> + Will Deacon
> + Peter Zijlstra
> +
> +
> +면책조항
> +
> +
> +이 문서는 명세서가 아닙니다; 이 문서는 완벽하지 않은데, 간결성을 위해 의도된
> +부분도 있고, 의도하진 않았지만 사람에 의해 쓰였다보니 그러한 부분도 있습니다.
I will add my opinion in korean.
그러한 부분 -> 불완전한 부분
> +이 문서는 리눅스에서 제공하는 다양한 메모리 배리어들을 사용하기 위한
> +안내서입니다만 뭔가 이상하다 싶으면 (그런게 많을 겁니다) 질문을 부탁드립니다.
> +
> +다시 말하지만, 이 문서는 리눅스가 하드웨어에 기대하는 사항에 대한 명세서가
> +아닙니다.
> +
> +이 문서의 목적은 두가지입니다:
> +
> + (1) 어떤 특정 배리어에 대해 기대할 수 있는 최소한의 기능을 명세하기 위해서,
> + 그리고
> +
> + (2) 사용 가능한 배리어들에 대해 어떻게 사용해야 하는지에 대한 안내를 제공하기
> + 위해서.
> +
> +어떤 아키텍쳐는 특정한 배리어들에 대해서는 여기서 이야기하는 최소한의
> +요구사항들보다 많은 기능을 제공할 수도 있습니다만, 여기서 이야기하는
> +요구사항들을 충족하지 않는 아키텍쳐가 있다면 그 아키텍쳐가 잘못된 것이란 점을
> +주의하시기 바랍니다.
주의하시기 -> 알아두시기
> +
> +또한, 일부 배리어는 특정 아키텍쳐에서는 해당 아키텍쳐의 동작 방식으로 인해
> +명시적으로 해당 배리어의 명시적 사용이 불필요해서 no-op 이 될수도 있음에
"명시적" 이라는 단어는 한번만...
> +주의하시기 바랍니다.
주의하시기 -> 알아두시기
> +===
> +추상 메모리 액세스 모델
> +===
> +
> +다음과 같이 추상화된 시스템 모델을 생각해 봅시다:
> +
> + ::
> + ::
> + ::
> + +---+ : ++ : +---+
> + | | : || : | |
> + | | : || : | |
> + | CPU 1 |<->| Memory |<->| CPU 2 |
> + | | : || : | |
> + | | : || : | |
> + +---+ : ++ : +---+
> + ^ : ^: ^
> + | : |: |
> + | : |: |
> + | : v: |
> + | : ++ : |
> + | : || : |
> + | : || : |
> + +-->| Device |<--+
> + : || :
> + : || :
> + : ++ :
> + ::
> +
> +각 CPU 는 메모리 액세스 오퍼레이션들을 발생시키는 프로그램을 실행합니다.
> +추상화된 CPU 모델에서 메모리 오퍼레이션들의 순서는 매우 완화되어 있고, CPU 는
> +프로그램이 인과관계를 어기지 않는 상태로 관리된다고 보일 수만 있다면 메모리
> +오퍼레이션들을 자신이 원하는 어떤 순서대로든 재배치해 실행할 수 있습니다.
영어는 긴 문장을 자주 사용하는 것 같아요. 반면에 한국어는 문장이 길어지면
읽기가 좀더 어려워 지는 것 같습니다. 필요하면 여러 문장 이상으로 분리하는
것이 좋을 것 같습니다. 이 문장도 두 문장으로 분리하는 게 더 좋지 않을까요?
> +비슷하게, 컴파일러 또한 프로그램의 정상적 동작을 해치지 않는 한도 내에서는 어떤
> +순서로든 자신이 원하는 대로 명령어들을 재배치 할 수 있습니다.
> +
> +따라서 위의 다어그램에서 한 CPU가 수행하는 메모리 오퍼레이션의 효과는
> +오퍼레이션이 CPU 와 시스템의 다른 부분들 사이의 인터페이스 (점선) 를 지나갈 때
> +시스템의 나머지 부분들에 전파됩니다.
따라서 위의 다*이*어그램에서 한 CPU가 수행하는 메오리 오퍼레이션의 결과는
오퍼레이션이 CPU와 시스템의 다른 부분들 사이의 인터페이스(점선)를 지날 때
시스템의 나머지 부분들이 인지할 수 있게 됩니다.
> +
> +
> +예를 들어, 다음의 일련의 이벤트들을 생각해 봅시다:
> +
> + CPU 1 CPU 2
> + === ===
> + { A == 1; B == 2 }
> + A = 3; x = B;
> + B = 4; y = A;
> +
> +그림의 가운데 위치한 메모리 시스템에 보여지게 될 액세스들은 다음의 총 24개 서로
> +다른 조합으로 재구성될 수 있습니다:
그림 가운데에 위치한 메모리 시스템에 보여지게 되는 엑세스 조합은 (...)
> +
> + STORE A=3, STORE B=4, y=LOAD A->3,x=LOAD B->4
> + STORE A=3, STORE B=4, x=LOAD B->4,y=LOAD A->3
> + STORE A=3, y=LOAD A->3,STORE B=4, x=LOAD B->4
> + STORE A=3, y=LOAD A->3,x=LOAD B->2,STORE B=4
> + STORE A=3, x=LOAD B->2,STORE B=4, y=LOAD A->3
> + STORE A=3, x=LOAD B->2,y=LOAD A->3,STORE B=4
> + STORE B=4, STORE A=3, y=LOAD A->3,x=LOAD B->4
> + STORE B=4, ...
> + ...
> +
> +따라서 다음의 네가지 조합의 결과가 나올 수 있습니다:
(...) 조합이 나올 수 있습니다.
> +
> + x == 2, y == 1
> + x == 2, y == 3
> + x == 4, y == 1
> + x == 4, y == 3
> +
> +
> +더욱이, 한 CPU 에 의해 메모리 시스템에 행해진 스토어 오퍼레이션들은 다른 CPU 의
> +로드 오퍼레이션 들에 스토어가 행해진 순서와 다른 순서로 읽혀질 수 있습니다.
훨씬 읽기 좋아지긴 했지만, 아직도 직역을 해서 읽기 어색한 부분이이 꽤 남아
있는 것 같습니다. 수정 부탁드립니다.
(..) 한 CPU가 메모리 시스템에 반영한 스토어 오퍼레이션들은 다른 CPU에서
로드 오퍼레이션을 통해서 인지할 수 있는데, 이 때 스토어가 반영된 순서대로
보여지지 않을 수 있습니다.
> +
> +
> +예로, 아래의 일련의 이벤트들을 생각해 봅시다:
> +
> + CPU 1 CPU 2
> + === ===
> + { A == 1, B == 2, C == 3, P == &A, Q == &C }
> + B = 4; Q = P;
> + P = &B D = *Q;
> +
> +D 로 읽혀지는 값은 CPU 2 에서 P 로부터 읽혀진 주소값에 의존적이기 때문에 여기엔
> +분명한 데이터 의존성이 있습니다. 이 이벤트들의 실행 결과로는 아래의 결과들이
> +모두 나타날 수 있습니다:
> +
> + (Q == &A) and (D == 1)
> + (Q == &B) and (D == 2)
> + (Q == &B) and (D == 4)
> +
> +CPU 2 는 *Q 의 로드를 요청하기 전에 P 를 Q 에 넣기
[PATCH v2 0/3] dma, nvme, powerpc: introduce and implement DMA_ATTR_NO_WARN
This patchset introduces dma_attr DMA_ATTR_NO_WARN (just like __GFP_NOWARN), which tells the DMA-mapping subsystem to suppress allocation failure reports. On some architectures allocation failures are reported with error messages to the system logs. Although this can help to identify and debug problems, drivers which handle failures (eg, retry later) have no problems with them, and can actually flood the system logs with error messages that aren't any problem at all, depending on the implementation of the retry mechanism. So, this provides a way for drivers to avoid those error messages on calls where allocation failures are not a problem, and shouldn't bother the logs. - Patch 1/3 introduces and documents the new dma_attr. - Patch 2/3 implements it on the nvme driver (which might repeatedly trip on allocation failures due to high load, flooding system logs with error messages at least on powerpc: "iommu_alloc failed") - Patch 3/3 implements support for it on powerpc arch (where this problem was observed. It's possible to extend support for more archs if the patchset is welcome). Changelog: v2: - address warnings from checkpatch.pl (line wrapping and typos) Mauricio Faria de Oliveira (3): dma: introduce DMA_ATTR_NO_WARN nvme: implement DMA_ATTR_NO_WARN powerpc: implement DMA_ATTR_NO_WARN Documentation/DMA-attributes.txt | 17 + arch/powerpc/kernel/iommu.c | 6 -- drivers/nvme/host/pci.c | 12 ++-- include/linux/dma-attrs.h| 1 + 4 files changed, 32 insertions(+), 4 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] dma: introduce DMA_ATTR_NO_WARN
Introduce the DMA_ATTR_NO_WARN attribute, and document it.
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
v2:
- address warnings from checkpatch.pl (line wrapping and typos)
Documentation/DMA-attributes.txt | 17 +
include/linux/dma-attrs.h| 1 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index e8cf9cf..48150c6 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -126,3 +126,20 @@ means that we won't try quite as hard to get them.
NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM,
though ARM64 patches will likely be posted soon.
+
+DMA_ATTR_NO_WARN
+
+
+This tells the DMA-mapping subsystem to suppress allocation failure reports
+(similarly to __GFP_NOWARN).
+
+On some architectures allocation failures are reported with error messages
+to the system logs. Although this can help to identify and debug problems,
+drivers which handle failures (eg, retry later) have no problems with them,
+and can actually flood the system logs with error messages that aren't any
+problem at all, depending on the implementation of the retry mechanism.
+
+So, this provides a way for drivers to avoid those error messages on calls
+where allocation failures are not a problem, and shouldn't bother the logs.
+
+NOTE: At the moment DMA_ATTR_NO_WARN is only implemented on PowerPC.
diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
index f3c5aea..0577389 100644
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -19,6 +19,7 @@ enum dma_attr {
DMA_ATTR_SKIP_CPU_SYNC,
DMA_ATTR_FORCE_CONTIGUOUS,
DMA_ATTR_ALLOC_SINGLE_PAGES,
+ DMA_ATTR_NO_WARN,
DMA_ATTR_MAX,
};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] nvme: implement DMA_ATTR_NO_WARN
Use the DMA_ATTR_NO_WARN attribute on dma_map_sg() calls of nvme driver. Signed-off-by: Mauricio Faria de Oliveira Reviewed-by: Gabriel Krisman Bertazi --- Changelog: v2: - address warnings from checkpatch.pl (line wrapping and typos) drivers/nvme/host/pci.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index d1a8259..a7ccad8 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -65,6 +66,8 @@ MODULE_PARM_DESC(use_cmb_sqes, "use controller's memory buffer for I/O SQes"); static struct workqueue_struct *nvme_workq; +static DEFINE_DMA_ATTRS(nvme_dma_attrs); + struct nvme_dev; struct nvme_queue; @@ -498,7 +501,8 @@ static int nvme_map_data(struct nvme_dev *dev, struct request *req, goto out; ret = BLK_MQ_RQ_QUEUE_BUSY; - if (!dma_map_sg(dev->dev, iod->sg, iod->nents, dma_dir)) + if (!dma_map_sg_attrs(dev->dev, iod->sg, iod->nents, dma_dir, + &nvme_dma_attrs)) goto out; if (!nvme_setup_prps(dev, req, size)) @@ -516,7 +520,8 @@ static int nvme_map_data(struct nvme_dev *dev, struct request *req, if (rq_data_dir(req)) nvme_dif_remap(req, nvme_dif_prep); - if (!dma_map_sg(dev->dev, &iod->meta_sg, 1, dma_dir)) + if (!dma_map_sg_attrs(dev->dev, &iod->meta_sg, 1, dma_dir, + &nvme_dma_attrs)) goto out_unmap; } @@ -2118,6 +2123,9 @@ static int __init nvme_init(void) result = pci_register_driver(&nvme_driver); if (result) destroy_workqueue(nvme_workq); + + dma_set_attr(DMA_ATTR_NO_WARN, &nvme_dma_attrs); + return result; } -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] powerpc: implement DMA_ATTR_NO_WARN
Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code.
Signed-off-by: Mauricio Faria de Oliveira
---
Changelog:
v2:
- address warnings from checkpatch.pl (line wrapping and typos)
arch/powerpc/kernel/iommu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index a8e3490..f1e20ea 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -479,7 +479,8 @@ int ppc_iommu_map_sg(struct device *dev, struct iommu_table
*tbl,
/* Handle failure */
if (unlikely(entry == DMA_ERROR_CODE)) {
- if (printk_ratelimit())
+ if (unlikely(!dma_get_attr(DMA_ATTR_NO_WARN, attrs)) &&
+ printk_ratelimit())
dev_info(dev, "iommu_alloc failed, tbl %p "
"vaddr %lx npages %lu\n", tbl, vaddr,
npages);
@@ -776,7 +777,8 @@ dma_addr_t iommu_map_page(struct device *dev, struct
iommu_table *tbl,
mask >> tbl->it_page_shift, align,
attrs);
if (dma_handle == DMA_ERROR_CODE) {
- if (printk_ratelimit()) {
+ if (unlikely(!dma_get_attr(DMA_ATTR_NO_WARN, attrs)) &&
+ printk_ratelimit()) {
dev_info(dev, "iommu_alloc failed, tbl %p "
"vaddr %p npages %d\n", tbl, vaddr,
npages);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] nvme: implement DMA_ATTR_NO_WARN
On 07/06/2016 09:41 PM, Gabriel Krisman Bertazi wrote: checkpatch.pl complains about line wrapping. Other than that, this looks good to me. I'll submit a v2 w/ that and typos fixed. Thanks for reviewing. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] drm: Add API for capturing frame CRCs
Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:
dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data
Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.
v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
generation gets enabled for the first time.
Signed-off-by: Tomeu Vizoso
---
Documentation/gpu/drm-uapi.rst| 6 +
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_crtc.c| 11 ++
drivers/gpu/drm/drm_debugfs.c | 36 +++-
drivers/gpu/drm/drm_debugfs_crc.c | 394 ++
drivers/gpu/drm/drm_drv.c | 9 +
drivers/gpu/drm/drm_internal.h| 10 +
include/drm/drmP.h| 5 +
include/drm/drm_crtc.h| 40
include/drm/drm_debugfs_crc.h | 71 +++
10 files changed, 583 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
create mode 100644 include/drm/drm_debugfs_crc.h
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 536bf3eaadd4..33f778696ccd 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -109,3 +109,9 @@ interfaces. Especially since all hardware-acceleration
interfaces to
userspace are driver specific for efficiency and other reasons these
interfaces can be rather substantial. Hence every driver has its own
chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+ :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e3dba6f44a79..b53b5aaaeb4d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,8 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o drm_atomic.o drm_bridge.o
+ drm_modeset_lock.o drm_atomic.o drm_bridge.o \
+ drm_debugfs_crc.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 10b73f68c023..48155e0439df 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -738,6 +739,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
if (cursor)
cursor->possible_crtcs = 1 << drm_crtc_index(crtc);
+#ifdef CONFIG_DEBUG_FS
+ spin_lock_init(&crtc->crc.lock);
+ init_waitqueue_head(&crtc->crc.wq);
+#endif
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(&crtc->base, config->prop_active, 0);
drm_object_attach_property(&crtc->base, config->prop_mode_id,
0);
@@ -764,6 +770,11 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
* the indices on the drm_crtc after us in the crtc_list.
*/
+#ifdef CONFIG_DEBUG_FS
+ drm_debugfs_crtc_remove(crtc);
+ kfree(crtc->crc.source);
+#endif
+
kfree(crtc->gamma_store);
crtc->gamma_store = NULL;
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index fa10cef2ba37..73530cbf1316 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -415,5 +415,39 @@ void drm_debugfs_connector_remove(struct drm_connector
*connector)
connector->debugfs_entry = NULL;
}
-#endif /* CONFIG_DEBUG_FS */
+int drm_debugfs_crtc_add(struct drm_crtc *crtc)
+{
+ struct drm_minor *minor = crtc->dev->primary;
+ struct dentry *root;
+ char *name;
+
+ name = kasprintf(GFP_KERNEL, "crtc-%d", crtc->index);
+ if (!name)
+ return -ENOMEM;
+ root = debugfs_create_dir(name, minor->debugfs_root);
+ kfree(name);
+ if (!root)
+ return -ENOMEM;
+
+ crtc->debugfs_entry = root;
+
+ if (drm_debugfs_crtc_crc_add(crtc))
+ goto error;
+
+ return 0;
+
+error:
+ debugfs_remove_recursive(crtc->debugfs_entry);
+ crtc->debugfs_entry = NULL;
+ return -ENOMEM;
+}
+
+void drm_debugfs_crtc_remove(struct drm_crtc *crtc)
+{
+ debugfs_remove_recursive(crtc->debugfs_entry);
+
+ crtc->debugfs_entry = NULL;
+}
+
+#endif /* CONFIG_DEBUG_FS */
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
new file mode 100644
index ..7995600bebf0
--- /dev/null
+++ b/drivers/gpu/
[PATCH v2 0/3] New debugfs API for capturing CRC of frames
Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are exected to be identical, also have identical CRC values. Other drivers for hardware that can provide frame CRCs (including eDP panels that support self-refresh) can easily implement the new callback and provide userspace with the CRC values. Thanks, Tomeu Tomeu Vizoso (3): drm/i915/debugfs: Move out pipe CRC code drm: Add API for capturing frame CRCs drm/i915: Use new CRC debugfs API Documentation/gpu/drm-uapi.rst| 6 + drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/drm_crtc.c| 11 + drivers/gpu/drm/drm_debugfs.c | 36 +- drivers/gpu/drm/drm_debugfs_crc.c | 394 ++ drivers/gpu/drm/drm_drv.c | 9 + drivers/gpu/drm/drm_internal.h| 10 + drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 892 +-- drivers/gpu/drm/i915/i915_irq.c | 57 +- drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 6 + drivers/gpu/drm/i915/intel_pipe_crc.c | 970 ++ include/drm/drmP.h| 5 + include/drm/drm_crtc.h| 40 ++ include/drm/drm_debugfs_crc.h | 71 +++ 16 files changed, 1597 insertions(+), 916 deletions(-) create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c create mode 100644 include/drm/drm_debugfs_crc.h -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] drm: Add API for capturing frame CRCs
On Thu, Jul 07, 2016 at 05:06:08PM +0200, Tomeu Vizoso wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start and stop generating frame CRCs and can add entries to the output
> by calling drm_crtc_add_crc_entry.
>
> v2:
> - Lots of good fixes suggested by Thierry.
> - Added documentation.
> - Changed the debugfs layout.
> - Moved to allocate the entries circular queue once when frame
> generation gets enabled for the first time.
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> Documentation/gpu/drm-uapi.rst| 6 +
> drivers/gpu/drm/Makefile | 3 +-
> drivers/gpu/drm/drm_crtc.c| 11 ++
> drivers/gpu/drm/drm_debugfs.c | 36 +++-
> drivers/gpu/drm/drm_debugfs_crc.c | 394
> ++
> drivers/gpu/drm/drm_drv.c | 9 +
> drivers/gpu/drm/drm_internal.h| 10 +
> include/drm/drmP.h| 5 +
> include/drm/drm_crtc.h| 40
> include/drm/drm_debugfs_crc.h | 71 +++
> 10 files changed, 583 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
> create mode 100644 include/drm/drm_debugfs_crc.h
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 536bf3eaadd4..33f778696ccd 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -109,3 +109,9 @@ interfaces. Especially since all hardware-acceleration
> interfaces to
> userspace are driver specific for efficiency and other reasons these
> interfaces can be rather substantial. Hence every driver has its own
> chapter.
> +
> +Testing and validation
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> + :doc: CRC ABI
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index e3dba6f44a79..b53b5aaaeb4d 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -12,7 +12,8 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \
> drm_info.o drm_debugfs.o drm_encoder_slave.o \
> drm_trace_points.o drm_global.o drm_prime.o \
> drm_rect.o drm_vma_manager.o drm_flip_work.o \
> - drm_modeset_lock.o drm_atomic.o drm_bridge.o
> + drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> + drm_debugfs_crc.o
>
> drm-$(CONFIG_COMPAT) += drm_ioc32.o
> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 10b73f68c023..48155e0439df 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> #include "drm_crtc_internal.h"
> #include "drm_internal.h"
> @@ -738,6 +739,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> if (cursor)
> cursor->possible_crtcs = 1 << drm_crtc_index(crtc);
>
> +#ifdef CONFIG_DEBUG_FS
> + spin_lock_init(&crtc->crc.lock);
> + init_waitqueue_head(&crtc->crc.wq);
> +#endif
> +
> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> drm_object_attach_property(&crtc->base, config->prop_active, 0);
> drm_object_attach_property(&crtc->base, config->prop_mode_id,
> 0);
> @@ -764,6 +770,11 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
>* the indices on the drm_crtc after us in the crtc_list.
>*/
>
> +#ifdef CONFIG_DEBUG_FS
> + drm_debugfs_crtc_remove(crtc);
> + kfree(crtc->crc.source);
> +#endif
> +
> kfree(crtc->gamma_store);
> crtc->gamma_store = NULL;
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index fa10cef2ba37..73530cbf1316 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -415,5 +415,39 @@ void drm_debugfs_connector_remove(struct drm_connector
> *connector)
> connector->debugfs_entry = NULL;
> }
>
> -#endif /* CONFIG_DEBUG_FS */
> +int drm_debugfs_crtc_add(struct drm_crtc *crtc)
> +{
> + struct drm_minor *minor = crtc->dev->primary;
> + struct dentry *root;
> + char *name;
> +
> + name = kasprintf(GFP_KERNEL, "crtc-%d", crtc->index);
> + if (!name)
> + return -ENOMEM;
>
> + root = debugfs_create_dir(name, minor->debugfs_root);
> + kfree(name);
> + if (!root)
> + return -ENOMEM;
> +
> + crtc->debugfs_entry = root;
> +
> + if (drm_debugfs_crtc_crc_add(crtc))
> + goto error;
> +
> + return 0;
> +
> +error:
> + debugfs_remove_recursive(crtc->debugfs_entry);
> + crtc->debugfs_entry = NULL;
> + return -ENOMEM;
> +}
> +
> +void drm_debugfs_crtc_remove(struct drm_crtc *crtc)
> +{
> + debugfs_remove_re
Re: [PATCH] capabilities: add capability cgroup controller
On 07/07/16 09:16, Petr Mladek wrote: > On Sun 2016-07-03 15:08:07, Topi Miettinen wrote: >> The attached patch would make any uses of capabilities generate audit >> messages. It works for simple tests as you can see from the commit >> message, but unfortunately the call to audit_cgroup_list() deadlocks the >> system when booting a full blown OS. There's no deadlock when the call >> is removed. >> >> I guess that in some cases, cgroup_mutex and/or css_set_lock could be >> already held earlier before entering audit_cgroup_list(). Holding the >> locks is however required by task_cgroup_from_root(). Is there any way >> to avoid this? For example, only print some kind of cgroup ID numbers >> (are there unique and stable IDs, available without locks?) for those >> cgroups where the task is registered in the audit message? > > I am not sure if anyone know what really happens here. I suggest to > enable lockdep. It might detect possible deadlock even before it > really happens, see Documentation/locking/lockdep-design.txt > > It can be enabled by > >CONFIG_PROVE_LOCKING=y > > It depends on > > CONFIG_DEBUG_KERNEL=y > > and maybe some more options, see lib/Kconfig.debug Thanks a lot! I caught this stack dump: starting version 230 [3.416647] [ cut here ] [3.417310] WARNING: CPU: 0 PID: 95 at /home/topi/d/linux.git/kernel/locking/lockdep.c:2871 lockdep_trace_alloc+0xb4/0xc0 [3.417605] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [3.417923] Modules linked in: [3.418288] CPU: 0 PID: 95 Comm: systemd-udevd Not tainted 4.7.0-rc5+ #97 [3.418444] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [3.418726] 0086 7970f3b0 8816fb00 813c9c45 [3.418993] 8816fb50 8816fb40 81091e9b [3.419176] 0b3705e2c798 0046 0410 [3.419374] Call Trace: [3.419511] [] dump_stack+0x67/0x92 [3.419644] [] __warn+0xcb/0xf0 [3.419745] [] warn_slowpath_fmt+0x5f/0x80 [3.419868] [] lockdep_trace_alloc+0xb4/0xc0 [3.419988] [] kmem_cache_alloc_node+0x42/0x600 [3.420156] [] ? debug_lockdep_rcu_enabled+0x1d/0x20 [3.420170] [] __alloc_skb+0x5b/0x1d0 [3.420170] [] audit_log_start+0x29b/0x480 [3.420170] [] ? __lock_task_sighand+0x95/0x270 [3.420170] [] audit_log_cap_use+0x39/0xf0 [3.420170] [] ns_capable+0x45/0x70 [3.420170] [] capable+0x17/0x20 [3.420170] [] oom_score_adj_write+0x150/0x2f0 [3.420170] [] __vfs_write+0x37/0x160 [3.420170] [] ? update_fast_ctr+0x17/0x30 [3.420170] [] ? percpu_down_read+0x49/0x90 [3.420170] [] ? __sb_start_write+0xb7/0xf0 [3.420170] [] ? __sb_start_write+0xb7/0xf0 [3.420170] [] vfs_write+0xb8/0x1b0 [3.420170] [] ? __fget_light+0x66/0x90 [3.420170] [] SyS_write+0x58/0xc0 [3.420170] [] do_syscall_64+0x5c/0x300 [3.420170] [] entry_SYSCALL64_slow_path+0x25/0x25 [3.420170] ---[ end trace fb586899fb556a5e ]--- [3.447922] random: systemd-udevd urandom read with 3 bits of entropy available [4.014078] clocksource: Switched to clocksource tsc Begin: Loading essential drivers ... done. This is with qemu and the boot continues normally. With real computer, there's no such output and system just seems to freeze. Could it be possible that the deadlock happens because there's some IO towards /sys/fs/cgroup, which causes a capability check and that in turn causes locking problems when we try to print cgroup list? -Topi -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/9] x86/mm: memory area address KASLR
On Tue, Jun 21, 2016 at 8:46 PM, Kees Cook wrote: > This is v7 of Thomas Garnier's KASLR for memory areas (physical memory > mapping, vmalloc, vmemmap). It expects to be applied on top of the > x86/boot tip. > > The current implementation of KASLR randomizes only the base address of > the kernel and its modules. Research was published showing that static > memory addresses can be found and used in exploits, effectively ignoring > base address KASLR: > >The physical memory mapping holds most allocations from boot and >heap allocators. Knowning the base address and physical memory >size, an attacker can deduce the PDE virtual address for the vDSO >memory page. This attack was demonstrated at CanSecWest 2016, in >the "Getting Physical: Extreme Abuse of Intel Based Paged Systems" >https://goo.gl/ANpWdV (see second part of the presentation). The >exploits used against Linux worked successfuly against 4.6+ but fail >with KASLR memory enabled (https://goo.gl/iTtXMJ). Similar research >was done at Google leading to this patch proposal. Variants exists >to overwrite /proc or /sys objects ACLs leading to elevation of >privileges. These variants were tested against 4.6+. > > This set of patches randomizes the base address and padding of three > major memory sections (physical memory mapping, vmalloc, and vmemmap). > It mitigates exploits relying on predictable kernel addresses in these > areas. This feature can be enabled with the CONFIG_RANDOMIZE_MEMORY > option. (This CONFIG, along with CONFIG_RANDOMIZE may be renamed in > the future, but stands for now as other architectures continue to > implement KASLR.) > > Padding for the memory hotplug support is managed by > CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. The default value is 10 > terabytes. > > The patches were tested on qemu & physical machines. Xen compatibility was > also verified. Multiple reboots were used to verify entropy for each > memory section. > > Notable problems that needed solving: > - The three target memory sections need to not be at the same place >across reboots. > - The physical memory mapping can use a virtual address not aligned on >the PGD page table. > - Reasonable entropy is needed early at boot before get_random_bytes() >is available. > - Memory hotplug needs KASLR padding. > > Patches: > - 1: refactor KASLR functions (moves them from boot/compressed/ into lib/) > - 2: clarifies the variables used for physical mapping. > - 3: PUD virtual address support for physical mapping. > - 4: split out the trampoline PGD > - 5: KASLR memory infrastructure code > - 6: randomize base of physical mapping region > - 7: randomize base of vmalloc region > - 8: randomize base of vmemmap region > - 9: provide memory hotplug padding support > > There is no measurable performance impact: > > - Kernbench shows almost no difference (-+ less than 1%). > - Hackbench shows 0% difference on average (hackbench 90 repeated 10 times). Hi again, Just a friendly ping -- I'd love to get this into -tip for wider testing. Thanks! -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] Doc/memory-barriers: Add Korean translation
2016-07-07 21:00 GMT+09:00 Byungchul Park :
> On Mon, Jul 04, 2016 at 08:27:08AM +0900, SeongJae Park wrote:
>> +===
>> +이 문서는
>> +Documentation/memory-barriers.txt
>> +의 한글 번역입니다.
>> +
>> +역자： 박성재
>> +===
>> +
>> +
>> + =
>> + 리눅스 커널 메모리 배리어
>> + =
>> +
>> +저자: David Howells
>> + Paul E. McKenney
>> + Will Deacon
>> + Peter Zijlstra
>> +
>> +
>> +면책조항
>> +
>> +
>> +이 문서는 명세서가 아닙니다; 이 문서는 완벽하지 않은데, 간결성을 위해 의도된
>> +부분도 있고, 의도하진 않았지만 사람에 의해 쓰였다보니 그러한 부분도 있습니다.
>
> I will add my opinion in korean.
Thank you for kind and faithful review. I agree with most of your opinions and
suggestions. Most of your suggestions looks much better than mine.
However, I also have some different opinion. I want to emphasize the fact that
(1) CPUs 'issue' memory operations to memory system as they want, (2) memory
system 'executes' those operations as they want, and (3) CPUs 'perceive' the
'effects' of the operation executions as they want. I want to emphasize the
fact in document because I think most confusion about memory ordering comes
from vague understanding about the relation. To my perspective, few of your
suggestions could enhance readability but could dim the point, too. I have
appended the opinion in Korean line by line, too. So, if you do not opposed
to, I will enhance the text again while keeping the point.
>
> 그러한 부분 -> 불완전한 부분
네, 그게 더 좋을 것 같네요.
>
>> +이 문서는 리눅스에서 제공하는 다양한 메모리 배리어들을 사용하기 위한
>> +안내서입니다만 뭔가 이상하다 싶으면 (그런게 많을 겁니다) 질문을 부탁드립니다.
>> +
>> +다시 말하지만, 이 문서는 리눅스가 하드웨어에 기대하는 사항에 대한 명세서가
>> +아닙니다.
>> +
>> +이 문서의 목적은 두가지입니다:
>> +
>> + (1) 어떤 특정 배리어에 대해 기대할 수 있는 최소한의 기능을 명세하기 위해서,
>> + 그리고
>> +
>> + (2) 사용 가능한 배리어들에 대해 어떻게 사용해야 하는지에 대한 안내를 제공하기
>> + 위해서.
>> +
>> +어떤 아키텍쳐는 특정한 배리어들에 대해서는 여기서 이야기하는 최소한의
>> +요구사항들보다 많은 기능을 제공할 수도 있습니다만, 여기서 이야기하는
>> +요구사항들을 충족하지 않는 아키텍쳐가 있다면 그 아키텍쳐가 잘못된 것이란 점을
>> +주의하시기 바랍니다.
>
> 주의하시기 -> 알아두시기
네, 더 나은 표현 같네요.
>
>> +
>> +또한, 일부 배리어는 특정 아키텍쳐에서는 해당 아키텍쳐의 동작 방식으로 인해
>> +명시적으로 해당 배리어의 명시적 사용이 불필요해서 no-op 이 될수도 있음에
>
> "명시적" 이라는 단어는 한번만...
넵
>
>> +주의하시기 바랍니다.
>
> 주의하시기 -> 알아두시기
네, 그게 나을 것 같습니다.
>
>> +===
>> +추상 메모리 액세스 모델
>> +===
>> +
>> +다음과 같이 추상화된 시스템 모델을 생각해 봅시다:
>> +
>> + ::
>> + ::
>> + ::
>> + +---+ : ++ : +---+
>> + | | : || : | |
>> + | | : || : | |
>> + | CPU 1 |<->| Memory |<->| CPU 2 |
>> + | | : || : | |
>> + | | : || : | |
>> + +---+ : ++ : +---+
>> + ^ : ^: ^
>> + | : |: |
>> + | : |: |
>> + | : v: |
>> + | : ++ : |
>> + | : || : |
>> + | : || : |
>> + +-->| Device |<--+
>> + : || :
>> + : || :
>> + : ++ :
>> + ::
>> +
>> +각 CPU 는 메모리 액세스 오퍼레이션들을 발생시키는 프로그램을 실행합니다.
>> +추상화된 CPU 모델에서 메모리 오퍼레이션들의 순서는 매우 완화되어 있고, CPU 는
>> +프로그램이 인과관계를 어기지 않는 상태로 관리된다고 보일 수만 있다면 메모리
>> +오퍼레이션들을 자신이 원하는 어떤 순서대로든 재배치해 실행할 수 있습니다.
>
> 영어는 긴 문장을 자주 사용하는 것 같아요. 반면에 한국어는 문장이 길어지면
> 읽기가 좀더 어려워 지는 것 같습니다. 필요하면 여러 문장 이상으로 분리하는
> 것이 좋을 것 같습니다. 이 문장도 두 문장으로 분리하는 게 더 좋지 않을까요?
>
>> +비슷하게, 컴파일러 또한 프로그램의 정상적 동작을 해치지 않는 한도 내에서는 어떤
>> +순서로든 자신이 원하는 대로 명령어들을 재배치 할 수 있습니다.
>> +
>> +따라서 위의 다어그램에서 한 CPU가 수행하는 메모리 오퍼레이션의 효과는
>> +오퍼레이션이 CPU 와 시스템의 다른 부분들 사이의 인터페이스 (점선) 를 지나갈 때
>> +시스템의 나머지 부분들에 전파됩니다.
>
> 따라서 위의 다*이*어그램에서 한 CPU가 수행하는 메오리 오퍼레이션의 결과는
> 오퍼레이션이 CPU와 시스템의 다른 부분들 사이의 인터페이스(점선)를 지날 때
> 시스템의 나머지 부분들이 인지할 수 있게 됩니다.
네, 오타가 있었네요. 문장도 좀 더 자연스러운 것 같습니다.
>
>> +
>> +
>> +예를 들어, 다음의 일련의 이벤트들을 생각해 봅시다:
>> +
>> + CPU 1 CPU 2
>> + === ===
>> + { A == 1; B == 2 }
>> + A = 3; x = B;
>> + B = 4; y = A;
>> +
>> +그림의 가운데 위치한 메모리 시스템에 보여지게 될 액세스들은 다음의 총 24개 서로
>> +다른 조합으로 재구성될 수 있습니다:
>
> 그림 가운데에 위치한 메모리 시스템에 보여지게 되는 엑세스 조합은 (...)
넵
>
>> +
>> + STORE A=3, STORE B=4, y=LOAD A->3,x=LOAD B->4
>> + STORE A=3, STORE B=4, x=LOAD B->4,y=LOAD A->3
>> + STORE A=3, y=LOAD A->3,STORE B=4, x=LOAD B->4
>> + STORE A=3, y=LOAD A->3,x=LOAD B->2,STORE B=4
>> + STORE A=3, x=LOAD B->2,STORE B=4
Re: [PATCH v4 3/3] Doc/memory-barriers: Add Korean translation
On Fri, Jul 08, 2016 at 07:50:39AM +0900, SeongJae Park wrote: > > I will add my opinion in korean. > > Thank you for kind and faithful review. I agree with most of your opinions > and > suggestions. Most of your suggestions looks much better than mine. > > However, I also have some different opinion. I want to emphasize the fact > that > (1) CPUs 'issue' memory operations to memory system as they want, (2) memory > system 'executes' those operations as they want, and (3) CPUs 'perceive' the > 'effects' of the operation executions as they want. I want to emphasize the > fact in document because I think most confusion about memory ordering comes > from vague understanding about the relation. To my perspective, few of your Right. I agree with you. > suggestions could enhance readability but could dim the point, too. I have > appended the opinion in Korean line by line, too. So, if you do not opposed > to, I will enhance the text again while keeping the point. ... > >> + > >> + STORE *A = 5, x = LOAD *D > >> + x = LOAD *D, STORE *A = 5 > >> + > >> +두번째 조합은 데이터를 읽어온 _후에_ 주소를 설정하므로, 잘못된 동작을 일으킬 > >> +것입니다. > >> + > >> + > >> +보장사항 > >> + > >> + > >> +CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니다: > >> + > >> + (*) 어떤 CPU 든, 의존성이 존재하는 메모리 액세스들은 해당 CPU 자신에게 > >> + 있어서는 해당 순서 그대로 요청됩니다. 즉, 다음에 대해서는: > > > > 요청됩니다. -> 수행됩니다. > > CPU (또는 디바이스) 는 메모리 오퍼레이션을 메모리 시스템에 '요청'하고 메모리 > 시스템에 의해 '수행'된 오퍼레이션의 '결과'를 '받거나' 다른 CPU 가 요청해서 > 메모리 시스템에서 수행된 오퍼레이션의 영향을 받게 되는 것인데, (1) CPU 가 > 코드와 순서를 바꿔서 요청할 수 있고, (2) (캐시를 포함한) 메모리 시스템이 요청된 > 오퍼레이션들을 임의의 순서로 수행할 수 있고, (3) 메모리 시스템의 수행 결과를 각 > CPU 가 임의의 순서로 볼 수 있게 된다 는 점이 메모리 순서 규칙의 기본이고, > 원문에 깔려 있는 기본 바탕이라 이해하고 있습니다. > > 이 경로를 단순하게 '수행한다'고 하게 되면 이 느낌을 헷갈리게 할 수도 있을 것 > 같아서, 가능한 CPU 는 '요청' 하고 메모리 시스템으로부터 결과를 '전달받는다'는 > 느낌을 문서 전체적으로 유지하는게 어떨까 싶습니다. Yes. Agree. > 이 문장의 경우 그냥 '요청'한다고 하니까 좀 어색한 것 같은데, 메모리 시스템에게 > 요청한다는 점을 좀 더 강조하는 식으로 수정하도록 하겠습니다. Agree. And it seems to be not easy :( > >> + > >> + Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q); > >> + > >> + CPU 는 다음과 같은 메모리 오퍼레이션들을 요청합니다: > > > > (...) 아래 메모리 오퍼레이션을 수행합니다: > > 역시 '요청'의 느낌은 살리도록 하겠습니다. Yes. > >> + (*) 특정 CPU 내에서 겹쳐서 행해지는 로드와 스토어 들은 그 CPU 안에서는 순서가 > > > > 메모리 영역이 겹치는 로드와 스토어가 한 CPU 내에서 수행될 경우, 해당 CPU > > 내에서 보았을 때에 그 순서는 바뀌지 않습니다. (...) > > 역시 '요청' 의 느낌은 남기도록 하겠습니다. Yes. > > -> 해당 CPU는 오직 다음 순서대로 메모리 오퍼레이션을 수행할 것입니다. > > 역시 '요청' 의 느낌은 남기도록 하겠습니다. Yes. > >> + a = LOAD *X, STORE *X = b > >> + > >> + 그리고 다음에 대해서는: > >> + > >> + WRITE_ONCE(*X, c); d = READ_ONCE(*X); > >> + > >> + CPU 는 오로지 다음의 명령만을 냅니다: > > > > (...) 오로지 아래 순서로 수행합니다. > > 역시 '요청' 의 느낌은 남기도록 하겠습니다. Yes. > > I think there are still many things literally translated. It makes it much > > harder to read. > > > > I think it's not the version with which I can add opinions line by line. > > Please review all sentences line by line carefully by yourself and make it > > more readable. > > > > I hope you don't hurry and spend more time to make it done. I believe you > > agree with it. > > Ok, I agree with your opinion. Actually, I have reviewed all sentences line > by > line for this version, too. However, it looks like it wasn't sufficient. I > will enhance it again. Thank you, Byungchul > > > > > Thank you, > > Byungchul -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
