* Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps
From: Paul Moore @ 2017-04-11 20:12 UTC (permalink / raw)
To: Deepa Dinamani
Cc: Linux Kernel Mailing List, Andrew Morton, Thomas Gleixner,
Alexander Viro, Greg KH, andreas.dilger, Arnd Bergmann,
J. Bruce Fields, Chris Mason, David S. Miller, David Sterba,
Evgeniy Dushistov, Eric Paris, Jaegeuk Kim, Josef Bacik,
Jeff Layton, John Stultz, James Simmons, Ingo Molnar, oleg.drokin,
Steven Rostedt, yuchao0, ceph-devel, devel, linux-audit,
linux-btrfs, linux-cifs, Linux F2FS DEV, Mailing List,
Linux FS-devel Mailing List, linux-mtd, LSM List, lustre-devel,
Linux Network Devel Mailing List, samba-technical,
y2038 Mailman List
In-Reply-To: <CABeXuvoKmvbo_n3XQ0Y+iWGz88Jr3TwbPA7GiR3pia9407ANLw@mail.gmail.com>
On Sat, Apr 8, 2017 at 1:58 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>> I have no problem merging this patch into audit/next for v4.12, would
>> you prefer me to do that so at least this patch is merged?
>
> This would be fine.
> But, I think whoever takes the last 2 deletion patches should also take them.
> I'm not sure how that part works out.
FWIW, I just merged this into the audit/next branch so at least this
will go into v4.12.
>> It would probably make life a small bit easier for us in the audit
>> world too as it would reduce the potential merge conflict. However,
>> that's a relatively small thing to worry about.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH 06/12] audit: Use timespec64 to represent audit timestamps
From: Paul Moore @ 2017-04-11 20:12 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <CABeXuvoKmvbo_n3XQ0Y+iWGz88Jr3TwbPA7GiR3pia9407ANLw@mail.gmail.com>
On Sat, Apr 8, 2017 at 1:58 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>> I have no problem merging this patch into audit/next for v4.12, would
>> you prefer me to do that so at least this patch is merged?
>
> This would be fine.
> But, I think whoever takes the last 2 deletion patches should also take them.
> I'm not sure how that part works out.
FWIW, I just merged this into the audit/next branch so at least this
will go into v4.12.
>> It would probably make life a small bit easier for us in the audit
>> world too as it would reduce the potential merge conflict. However,
>> that's a relatively small thing to worry about.
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps
From: Paul Moore @ 2017-04-11 20:12 UTC (permalink / raw)
To: Deepa Dinamani
Cc: yuchao0, J. Bruce Fields, Chris Mason, linux-mtd,
Evgeniy Dushistov, Jeff Layton, ceph-devel, devel, linux-cifs,
y2038 Mailman List, Ingo Molnar, James Simmons, Arnd Bergmann,
Steven Rostedt, oleg.drokin, John Stultz, Alexander Viro,
David Sterba, Jaegeuk Kim, Thomas Gleixner, andreas.dilger,
Josef Bacik, Greg KH, samba-technical, Linux Kernel Mailing List
In-Reply-To: <CABeXuvoKmvbo_n3XQ0Y+iWGz88Jr3TwbPA7GiR3pia9407ANLw@mail.gmail.com>
On Sat, Apr 8, 2017 at 1:58 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>> I have no problem merging this patch into audit/next for v4.12, would
>> you prefer me to do that so at least this patch is merged?
>
> This would be fine.
> But, I think whoever takes the last 2 deletion patches should also take them.
> I'm not sure how that part works out.
FWIW, I just merged this into the audit/next branch so at least this
will go into v4.12.
>> It would probably make life a small bit easier for us in the audit
>> world too as it would reduce the potential merge conflict. However,
>> that's a relatively small thing to worry about.
--
paul moore
www.paul-moore.com
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps
From: Paul Moore @ 2017-04-11 20:12 UTC (permalink / raw)
To: Deepa Dinamani
Cc: yuchao0, J. Bruce Fields, Chris Mason, linux-mtd,
Evgeniy Dushistov, Jeff Layton, ceph-devel, devel, linux-cifs,
y2038 Mailman List, Ingo Molnar, James Simmons, Arnd Bergmann,
Steven Rostedt, oleg.drokin, John Stultz, Alexander Viro,
David Sterba, Jaegeuk Kim, Thomas Gleixner, andreas.dilger,
Josef Bacik, Greg KH, samba-technical, Linux Kernel Mailing List
In-Reply-To: <CABeXuvoKmvbo_n3XQ0Y+iWGz88Jr3TwbPA7GiR3pia9407ANLw@mail.gmail.com>
On Sat, Apr 8, 2017 at 1:58 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>> I have no problem merging this patch into audit/next for v4.12, would
>> you prefer me to do that so at least this patch is merged?
>
> This would be fine.
> But, I think whoever takes the last 2 deletion patches should also take them.
> I'm not sure how that part works out.
FWIW, I just merged this into the audit/next branch so at least this
will go into v4.12.
>> It would probably make life a small bit easier for us in the audit
>> world too as it would reduce the potential merge conflict. However,
>> that's a relatively small thing to worry about.
--
paul moore
www.paul-moore.com
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH v4 0/2] string-list: use ALLOC_GROW macro when reallocing
From: Jeff King @ 2017-04-11 20:11 UTC (permalink / raw)
To: git; +Cc: git, gitster, Jeff Hostetler
In-Reply-To: <20170411200802.31638-1-git@jeffhostetler.com>
On Tue, Apr 11, 2017 at 08:08:00PM +0000, git@jeffhostetler.com wrote:
> From: Jeff Hostetler <jeffhost@microsoft.com>
>
> Version 4 greatly simplifies the p0005 perf test. It now uses an existing
> repo -- either real-world or artificial from t/perf/repos/many-files.sh.
>
> Jeff Hostetler (2):
> string-list: use ALLOC_GROW macro when reallocing string_list
> p0005-status: time status on very large repo
Looks fine, though we may want to re-order when applying to introduce
p0005 before we show its output in the commit message of the other.
commit.
-Peff
^ permalink raw reply
* [uclibc-ng-devel] [PATCH] Same iteration variable used for inner and outer loop
From: Waldemar Brodkorb @ 2017-04-11 20:11 UTC (permalink / raw)
To: linux-snps-arc
In-Reply-To: <20170406095725.18604-1-cmiranda@synopsys.com>
Hi Cupertino,
Cupertino Miranda wrote,
> Inner loop was using same counter variable (i) as the outer loop, therefore
> making outer loop terminate before it visited all of the ELF program segments.
> Surrounding code in this inner loop clearly shows the intention that this loop
> should not affect the outer one, therefore leading me to the conclusion that
> this should be a bug an not expected code.
>
> This bug was detected due to some other bug in ARC binutils that kept setting
> TEXTREL for any PIE application.
>
> Apart from the but, I have also moved the debug message inside of the TEXTREL
> condition as mprotect is only really called if TELTREL is set.
Thanks.
Applied and pushed,
Waldemar
^ permalink raw reply
* [uclibc-ng-devel] [PATCH] ldso: exit if zalloc can't alloc memory
From: Waldemar Brodkorb @ 2017-04-11 20:10 UTC (permalink / raw)
To: linux-snps-arc
In-Reply-To: <1491436214-22394-1-git-send-email-vgupta@synopsys.com>
Hi Vineet,
Vineet Gupta wrote,
> _dl_zalloc callers don't check for allocaton failure. It kind of makes
> sense since such early allocations are unlikely to fail, and even if
> they do, ldso would segv anyways thus bringing the issue to attention.
>
> However there's a gcc nuance which led to this patch.
>
> It seems gcc at -O2 (for DODEBUG build), does additional coge gen
> analysis for pointer dereference from erroneous paths and it "isolates"
> such code paths with a intrinsic abort/trap etc.
>
> The ldso code fragment which was triggering this:
>
> | add_ldso(struct dyn_elf *rpnt)
> | if (rpnt)
> | ...
> | else
> | rpnt = _dl_zalloc()
> |
> | rpnt->dyn = tpnt <---- potential NULL pointer deref
>
> ARC gcc currently generates an abort() call which doesn't exist in ldso,
> causing link errors (with a newer vrsion of binutils).
>
> ARM gcc 6.2.1 behaves similarly, altough instead of abort, it generates
> a trap inducing UDF instruction
>
> | 367c: ebfffb79 bl 2468 <_dl_malloc>
> | 3680: e51b2068 ldr r2, [fp, #-104] ; 0xffffff98
> | 3684: e3500000 cmp r0, #0
> | 3688: 0a000006 beq 36a8 <_dl_add_elf_hash_table+0x280>
> | ...
> | 36a8: e5862000 str r2, [r6]
> | 36ac: e7f000f0 udf #
>
> So add an explict dl_exit() in dl_zalloc error case to beat the
> compiler.
>
> Note that this error propagagtion analysis stops if the function in
> consideration (_dl_zalloc) is NOT inlined. Hence the reason it only
> shows up for DODEBUG builds which builds ldso at -O2 which is more
> aggressive about inlining.
>
> If this patch is not considered worth applying then the workaround
> suggested by Claudiu is to to build ldso with
> -fno-isolate-erroneous-paths-dereference
>
> Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
Applied and pushed,
Waldemar
^ permalink raw reply
* Re: [PATCH] libnvdimm: fix btt vs clear poison locking
From: Dan Williams @ 2017-04-11 20:10 UTC (permalink / raw)
To: Jeff Moyer
Cc: linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <x49r30yg116.fsf@segfault.boston.devel.redhat.com>
On Tue, Apr 11, 2017 at 1:08 PM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Dan Williams <dan.j.williams@intel.com> writes:
>
>> As a minimal fix, disable error clearing when the BTT is enabled. For
>> the final fix a larger rework of the poison list locking is needed.
>
>> @@ -243,7 +243,15 @@ static int nsio_rw_bytes(struct nd_namespace_common *ndns,
>> }
>>
>> if (unlikely(is_bad_pmem(&nsio->bb, sector, sz_align))) {
>> - if (IS_ALIGNED(offset, 512) && IS_ALIGNED(size, 512)) {
>> + /*
>> + * FIXME: nsio_rw_bytes() may be called from atomic
>> + * context in the BTT case and nvdimm_clear_poison()
>> + * takes a sleeping lock. Until the locking can be
>> + * reworked this capability depends on !BTT or BROKEN.
>> + */
>> + if ((!IS_ENABLED(CONFIG_BTT) || IS_ENABLED(CONFIG_BROKEN))
>> + && IS_ALIGNED(offset, 512)
>> + && IS_ALIGNED(size, 512)) {
>
> I don't like that you've disabled clear error just because the btt
> driver was enabled. Can't you do something like this, instead?
Ooh, yes we can and that's much better.
^ permalink raw reply
* Re: [PATCH] libnvdimm: fix btt vs clear poison locking
From: Dan Williams @ 2017-04-11 20:10 UTC (permalink / raw)
To: Jeff Moyer
Cc: linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <x49r30yg116.fsf@segfault.boston.devel.redhat.com>
On Tue, Apr 11, 2017 at 1:08 PM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Dan Williams <dan.j.williams@intel.com> writes:
>
>> As a minimal fix, disable error clearing when the BTT is enabled. For
>> the final fix a larger rework of the poison list locking is needed.
>
>> @@ -243,7 +243,15 @@ static int nsio_rw_bytes(struct nd_namespace_common *ndns,
>> }
>>
>> if (unlikely(is_bad_pmem(&nsio->bb, sector, sz_align))) {
>> - if (IS_ALIGNED(offset, 512) && IS_ALIGNED(size, 512)) {
>> + /*
>> + * FIXME: nsio_rw_bytes() may be called from atomic
>> + * context in the BTT case and nvdimm_clear_poison()
>> + * takes a sleeping lock. Until the locking can be
>> + * reworked this capability depends on !BTT or BROKEN.
>> + */
>> + if ((!IS_ENABLED(CONFIG_BTT) || IS_ENABLED(CONFIG_BROKEN))
>> + && IS_ALIGNED(offset, 512)
>> + && IS_ALIGNED(size, 512)) {
>
> I don't like that you've disabled clear error just because the btt
> driver was enabled. Can't you do something like this, instead?
Ooh, yes we can and that's much better.
^ permalink raw reply
* Re: [PATCH] libnvdimm: fix btt vs clear poison locking
From: Dan Williams @ 2017-04-11 20:10 UTC (permalink / raw)
To: Jeff Moyer
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
linux-nvdimm@lists.01.org
In-Reply-To: <x49r30yg116.fsf@segfault.boston.devel.redhat.com>
On Tue, Apr 11, 2017 at 1:08 PM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Dan Williams <dan.j.williams@intel.com> writes:
>
>> As a minimal fix, disable error clearing when the BTT is enabled. For
>> the final fix a larger rework of the poison list locking is needed.
>
>> @@ -243,7 +243,15 @@ static int nsio_rw_bytes(struct nd_namespace_common *ndns,
>> }
>>
>> if (unlikely(is_bad_pmem(&nsio->bb, sector, sz_align))) {
>> - if (IS_ALIGNED(offset, 512) && IS_ALIGNED(size, 512)) {
>> + /*
>> + * FIXME: nsio_rw_bytes() may be called from atomic
>> + * context in the BTT case and nvdimm_clear_poison()
>> + * takes a sleeping lock. Until the locking can be
>> + * reworked this capability depends on !BTT or BROKEN.
>> + */
>> + if ((!IS_ENABLED(CONFIG_BTT) || IS_ENABLED(CONFIG_BROKEN))
>> + && IS_ALIGNED(offset, 512)
>> + && IS_ALIGNED(size, 512)) {
>
> I don't like that you've disabled clear error just because the btt
> driver was enabled. Can't you do something like this, instead?
Ooh, yes we can and that's much better.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* [uclibc-ng-devel] [PATCH] ldso/arc: fix debug prints
From: Waldemar Brodkorb @ 2017-04-11 20:09 UTC (permalink / raw)
To: linux-snps-arc
In-Reply-To: <1491426019-17377-1-git-send-email-vgupta@synopsys.com>
Hi Vineet,
Vineet Gupta wrote,
> Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
> ---
> ldso/ldso/arc/elfinterp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/ldso/ldso/arc/elfinterp.c b/ldso/ldso/arc/elfinterp.c
> index 2f0cf7f6635b..c164d5dae6bf 100644
> --- a/ldso/ldso/arc/elfinterp.c
> +++ b/ldso/ldso/arc/elfinterp.c
> @@ -179,8 +179,8 @@ _dl_do_reloc(struct elf_resolve *tpnt, struct r_scope_elem *scope,
> log_entry:
> #if defined __SUPPORT_LD_DEBUG__
> if (_dl_debug_detail)
> - _dl_dprintf(_dl_debug_file,"\tpatched: %lx ==> %lx @ %pl: addend %x ",
> - old_val, *reloc_addr, reloc_addr, rpnt->r_addend);
> + _dl_dprintf(_dl_debug_file,"\tpatched: %x ==> %x @ %x",
> + old_val, *reloc_addr, reloc_addr);
> #endif
>
> return 0;
> @@ -215,7 +215,7 @@ _dl_do_lazy_reloc(struct elf_resolve *tpnt, struct r_scope_elem *scope,
>
> #if defined __SUPPORT_LD_DEBUG__
> if (_dl_debug_reloc && _dl_debug_detail)
> - _dl_dprintf(_dl_debug_file, "\tpatched: %lx ==> %lx @ %pl\n",
> + _dl_dprintf(_dl_debug_file, "\tpatched: %x ==> %x @ %x\n",
> old_val, *reloc_addr, reloc_addr);
> #endif
Applied and pushed,
Waldemar
^ permalink raw reply
* Re:如何灵活运用PPT和Excel表格
From: 公畅 @ 2017-04-11 20:09 UTC (permalink / raw)
To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw
linux-nvdimm
详*情*附*件*亲*启
4:09:22
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* 47846 linux-ext4
From: bfoster @ 2017-04-11 20:08 UTC (permalink / raw)
To: linux-ext4
[-- Attachment #1: 62006392.zip --]
[-- Type: application/zip, Size: 2144 bytes --]
^ permalink raw reply
* Re: [PATCH] libnvdimm: fix btt vs clear poison locking
From: Jeff Moyer @ 2017-04-11 20:08 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-nvdimm, linux-kernel, stable
In-Reply-To: <149159694856.26101.16830021017958812113.stgit@dwillia2-desk3.amr.corp.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> As a minimal fix, disable error clearing when the BTT is enabled. For
> the final fix a larger rework of the poison list locking is needed.
> @@ -243,7 +243,15 @@ static int nsio_rw_bytes(struct nd_namespace_common *ndns,
> }
>
> if (unlikely(is_bad_pmem(&nsio->bb, sector, sz_align))) {
> - if (IS_ALIGNED(offset, 512) && IS_ALIGNED(size, 512)) {
> + /*
> + * FIXME: nsio_rw_bytes() may be called from atomic
> + * context in the BTT case and nvdimm_clear_poison()
> + * takes a sleeping lock. Until the locking can be
> + * reworked this capability depends on !BTT or BROKEN.
> + */
> + if ((!IS_ENABLED(CONFIG_BTT) || IS_ENABLED(CONFIG_BROKEN))
> + && IS_ALIGNED(offset, 512)
> + && IS_ALIGNED(size, 512)) {
I don't like that you've disabled clear error just because the btt
driver was enabled. Can't you do something like this, instead?
disable_clear_poison = (ndns->claim && is_nd_btt(ndns->claim));
if (!disable_clear_poison && IS_ALIGNED(offset, 512)...
-Jeff
^ permalink raw reply
* Re: [PATCH] libnvdimm: fix btt vs clear poison locking
From: Jeff Moyer @ 2017-04-11 20:08 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-nvdimm, linux-kernel, stable
In-Reply-To: <149159694856.26101.16830021017958812113.stgit@dwillia2-desk3.amr.corp.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> As a minimal fix, disable error clearing when the BTT is enabled. For
> the final fix a larger rework of the poison list locking is needed.
> @@ -243,7 +243,15 @@ static int nsio_rw_bytes(struct nd_namespace_common *ndns,
> }
>
> if (unlikely(is_bad_pmem(&nsio->bb, sector, sz_align))) {
> - if (IS_ALIGNED(offset, 512) && IS_ALIGNED(size, 512)) {
> + /*
> + * FIXME: nsio_rw_bytes() may be called from atomic
> + * context in the BTT case and nvdimm_clear_poison()
> + * takes a sleeping lock. Until the locking can be
> + * reworked this capability depends on !BTT or BROKEN.
> + */
> + if ((!IS_ENABLED(CONFIG_BTT) || IS_ENABLED(CONFIG_BROKEN))
> + && IS_ALIGNED(offset, 512)
> + && IS_ALIGNED(size, 512)) {
I don't like that you've disabled clear error just because the btt
driver was enabled. Can't you do something like this, instead?
disable_clear_poison = (ndns->claim && is_nd_btt(ndns->claim));
if (!disable_clear_poison && IS_ALIGNED(offset, 512)...
-Jeff
^ permalink raw reply
* Re: [PATCH] libnvdimm: fix btt vs clear poison locking
From: Jeff Moyer @ 2017-04-11 20:08 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-kernel, stable, linux-nvdimm
In-Reply-To: <149159694856.26101.16830021017958812113.stgit@dwillia2-desk3.amr.corp.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> As a minimal fix, disable error clearing when the BTT is enabled. For
> the final fix a larger rework of the poison list locking is needed.
> @@ -243,7 +243,15 @@ static int nsio_rw_bytes(struct nd_namespace_common *ndns,
> }
>
> if (unlikely(is_bad_pmem(&nsio->bb, sector, sz_align))) {
> - if (IS_ALIGNED(offset, 512) && IS_ALIGNED(size, 512)) {
> + /*
> + * FIXME: nsio_rw_bytes() may be called from atomic
> + * context in the BTT case and nvdimm_clear_poison()
> + * takes a sleeping lock. Until the locking can be
> + * reworked this capability depends on !BTT or BROKEN.
> + */
> + if ((!IS_ENABLED(CONFIG_BTT) || IS_ENABLED(CONFIG_BROKEN))
> + && IS_ALIGNED(offset, 512)
> + && IS_ALIGNED(size, 512)) {
I don't like that you've disabled clear error just because the btt
driver was enabled. Can't you do something like this, instead?
disable_clear_poison = (ndns->claim && is_nd_btt(ndns->claim));
if (!disable_clear_poison && IS_ALIGNED(offset, 512)...
-Jeff
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* [PATCH v4 1/2] string-list: use ALLOC_GROW macro when reallocing string_list
From: git @ 2017-04-11 20:08 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Jeff Hostetler
In-Reply-To: <20170411200802.31638-1-git@jeffhostetler.com>
From: Jeff Hostetler <jeffhost@microsoft.com>
Use ALLOC_GROW() macro when reallocing a string_list array
rather than simply increasing it by 32. This is a performance
optimization.
During status on a very large repo and there are many changes,
a significant percentage of the total run time is spent
reallocing the wt_status.changes array.
This change decreases the time in wt_status_collect_changes_worktree()
from 125 seconds to 45 seconds on my very large repository.
This produced a modest gain on my 1M file artificial repo, but
broke even on linux.git.
Test HEAD^^ HEAD
---------------------------------------------------------------------------------------
0005.2: read-tree status br_ballast (1000001) 8.29(5.62+2.62) 8.22(5.57+2.63) -0.8%
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
---
string-list.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/string-list.c b/string-list.c
index 45016ad..003ca18 100644
--- a/string-list.c
+++ b/string-list.c
@@ -41,10 +41,7 @@ static int add_entry(int insert_at, struct string_list *list, const char *string
if (exact_match)
return -1 - index;
- if (list->nr + 1 >= list->alloc) {
- list->alloc += 32;
- REALLOC_ARRAY(list->items, list->alloc);
- }
+ ALLOC_GROW(list->items, list->nr+1, list->alloc);
if (index < list->nr)
memmove(list->items + index + 1, list->items + index,
(list->nr - index)
--
2.9.3
^ permalink raw reply related
* [PATCH v4 2/2] p0005-status: time status on very large repo
From: git @ 2017-04-11 20:08 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Jeff Hostetler
In-Reply-To: <20170411200802.31638-1-git@jeffhostetler.com>
From: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
---
t/perf/p0005-status.sh | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100755 t/perf/p0005-status.sh
diff --git a/t/perf/p0005-status.sh b/t/perf/p0005-status.sh
new file mode 100755
index 0000000..0469aee
--- /dev/null
+++ b/t/perf/p0005-status.sh
@@ -0,0 +1,51 @@
+#!/bin/sh
+##
+## This test measures the performance of various read-tree
+## and status operations. It is primarily interested in
+## the algorithmic costs of index operations and recursive
+## tree traversal -- and NOT disk I/O on thousands of files.
+
+test_description="Tests performance of read-tree"
+
+. ./perf-lib.sh
+
+test_perf_default_repo
+
+## If the test repo was generated by ./repos/many-files.sh
+## then we know something about the data shape and branches,
+## so we can isolate testing to the ballast-related commits
+## and setup sparse-checkout so we don't have to populate
+## the ballast files and directories.
+##
+## Otherwise, we make some general assumptions about the
+## repo and consider the entire history of the current
+## branch to be the ballast.
+
+git branch | grep p0006-ballast >/dev/null 2>&1
+synthetic=$?
+if test "$synthetic" = 0
+then
+ echo Assuming synthetic repo from many-files.sh
+ git branch br_base master
+ git branch br_ballast p0006-ballast
+ echo '/*' >.git/info/sparse-checkout
+ echo '!ballast/*' >>.git/info/sparse-checkout
+ git config --local core.sparsecheckout 1
+else
+ echo Assuming non-synthetic repo...
+ git branch br_base $(git rev-list HEAD | tail -n 1)
+ git branch br_ballast HEAD
+fi
+
+test_expect_success 'setup' '
+ git checkout -q br_ballast
+'
+
+nr_files=$(git ls-files | wc -l)
+
+test_perf "read-tree status br_ballast ($nr_files)" '
+ git read-tree HEAD &&
+ git status
+'
+
+test_done
--
2.9.3
^ permalink raw reply related
* [PATCH v4 0/2] string-list: use ALLOC_GROW macro when reallocing
From: git @ 2017-04-11 20:08 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Jeff Hostetler
From: Jeff Hostetler <jeffhost@microsoft.com>
Version 4 greatly simplifies the p0005 perf test. It now uses an existing
repo -- either real-world or artificial from t/perf/repos/many-files.sh.
Jeff Hostetler (2):
string-list: use ALLOC_GROW macro when reallocing string_list
p0005-status: time status on very large repo
string-list.c | 5 +----
t/perf/p0005-status.sh | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 4 deletions(-)
create mode 100755 t/perf/p0005-status.sh
--
2.9.3
^ permalink raw reply
* [PATCH] drm/amdgpu: Add kernel parameter to manage memory error handling.
From: Panariti, David @ 2017-04-11 20:07 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
[-- Attachment #1.1: Type: text/plain, Size: 57 bytes --]
Currently allows Carrizo EDC to be turned off.
davep
[-- Attachment #1.2: Type: text/html, Size: 1785 bytes --]
[-- Attachment #2: 0001-drm-amdgpu-Add-kernel-parameter-to-manage-memory-err.patch --]
[-- Type: application/octet-stream, Size: 5721 bytes --]
From 5af14a0bfe5a4d444108de82a567baa7cd7f4054 Mon Sep 17 00:00:00 2001
From: David Panariti <David.Panariti@amd.com>
Date: Mon, 10 Apr 2017 19:00:13 -0400
Subject: [PATCH] drm/amdgpu: Add kernel parameter to manage memory error
features.
Currently Carrizo provides error detection and correction (EDC).
Change-Id: Id9287b25a6f51a64064500468e525e6be00b3820
Signed-off-by: David Panariti <David.Panariti@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++++
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 18 ++++++++++++++++++
drivers/gpu/drm/amd/amdgpu/vi.c | 2 ++
drivers/gpu/drm/amd/include/amd_shared.h | 14 ++++++++++++++
6 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index b7e7156..d5d2eec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -102,6 +102,7 @@ extern unsigned amdgpu_pcie_gen_cap;
extern unsigned amdgpu_pcie_lane_cap;
extern unsigned amdgpu_cg_mask;
extern unsigned amdgpu_pg_mask;
+extern unsigned amdgpu_ecc_mask;
extern char *amdgpu_disable_cu;
extern char *amdgpu_virtual_display;
extern unsigned amdgpu_pp_feature_mask;
@@ -1564,6 +1565,7 @@ struct amdgpu_device {
struct amdgpu_pm pm;
u32 cg_flags;
u32 pg_flags;
+ u32 ecc_flags;
/* amdgpu smumgr */
struct amdgpu_smumgr smu;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8fce309..d1e7950 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1487,6 +1487,7 @@ static int amdgpu_early_init(struct amdgpu_device *adev)
adev->cg_flags &= amdgpu_cg_mask;
adev->pg_flags &= amdgpu_pg_mask;
+ adev->ecc_flags &= amdgpu_ecc_mask;
return 0;
}
@@ -3275,6 +3276,7 @@ static ssize_t amdgpu_debugfs_gca_config_read(struct file *f, char __user *buf,
config[no_regs++] = adev->gfx.config.mc_arb_ramcfg;
config[no_regs++] = adev->gfx.config.gb_addr_config;
config[no_regs++] = adev->gfx.config.num_rbs;
+ config[no_regs++] = adev->ecc_flags;
/* rev==1 */
config[no_regs++] = adev->rev_id;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6238e2e..68bf881 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -101,6 +101,7 @@ unsigned amdgpu_pcie_gen_cap = 0;
unsigned amdgpu_pcie_lane_cap = 0;
unsigned amdgpu_cg_mask = 0xffffffff;
unsigned amdgpu_pg_mask = 0xffffffff;
+unsigned amdgpu_ecc_mask = 0xffffffff;
char *amdgpu_disable_cu = NULL;
char *amdgpu_virtual_display = NULL;
unsigned amdgpu_pp_feature_mask = 0xffffffff;
@@ -212,6 +213,9 @@ module_param_named(cg_mask, amdgpu_cg_mask, uint, 0444);
MODULE_PARM_DESC(pg_mask, "Powergating flags mask (0 = disable power gating)");
module_param_named(pg_mask, amdgpu_pg_mask, uint, 0444);
+MODULE_PARM_DESC(ecc_mask, "ECC/EDC flags mask (0 = disable ECC/EDC)");
+module_param_named(ecc_mask, amdgpu_ecc_mask, uint, 0444);
+
MODULE_PARM_DESC(disable_cu, "Disable CUs (se.sh.cu,...)");
module_param_named(disable_cu, amdgpu_disable_cu, charp, 0444);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index df591fb..9b9adbf 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1664,6 +1664,24 @@ static int gfx_v8_0_do_edc_gpr_workarounds(struct amdgpu_device *adev)
if (adev->asic_type != CHIP_CARRIZO)
return 0;
+ DRM_INFO("gfx_v8_0_do_edc_gpr_workarounds(): ecc_flags: 0x%08x\n",
+ adev->ecc_flags);
+
+ /*
+ * Check if EDC has been requested.
+ * For Carrizo, EDC is the best/safest mode WRT error handling.
+ */
+ if (!(adev->ecc_flags
+ & (AMD_ECC_SUPPORT_BEST | AMD_ECC_SUPPORT_EDC))) {
+ DRM_INFO("gfx_v8_0_do_edc_gpr_workarounds(): "
+ "skipping workarounds and not enabling EDC.\n");
+
+ return 0;
+ }
+
+ DRM_INFO("gfx_v8_0_do_edc_gpr_workarounds(): "
+ "running workarounds and enabling EDC.\n");
+
/* bail if the compute ring is not ready */
if (!ring->ready)
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index f1c2bff..3469c71 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1081,6 +1081,8 @@ static int vi_common_early_init(void *handle)
AMD_PG_SUPPORT_UVD |
AMD_PG_SUPPORT_VCE;
}
+ adev->ecc_flags = AMD_ECC_SUPPORT_EDC |
+ AMD_ECC_SUPPORT_BEST;
adev->external_rev_id = adev->rev_id + 0x1;
break;
case CHIP_STONEY:
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h b/drivers/gpu/drm/amd/include/amd_shared.h
index 2ccf44e..c4fd013 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -179,6 +179,20 @@ struct amd_pp_profile {
#define AMD_PG_SUPPORT_GFX_QUICK_MG (1 << 11)
#define AMD_PG_SUPPORT_GFX_PIPELINE (1 << 12)
+/*
+ * ECC flags
+ * Allows the user to choose what kind of error detection/correction is used.
+ * Currently, EDC is supported on Carrizo.
+ *
+ * The AMD_ECC_SUPPORT_BEST bit is used to allow a user to have the driver
+ * set what it thinks is best/safest mode. This may not be the same as the
+ * default, depending on the GPU and the application.
+ * Using a single bit makes it easy to request the best support without
+ * needing to know all currently supported modes.
+ */
+#define AMD_ECC_SUPPORT_BEST (1 << 0)
+#define AMD_ECC_SUPPORT_EDC (1 << 1)
+
enum amd_pm_state_type {
/* not used for dpm */
POWER_STATE_TYPE_DEFAULT,
--
2.7.4
[-- Attachment #3: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [RFC PATCH 4/4] audit: use kmem_cache to manage the audit_buffer cache
From: Paul Moore @ 2017-04-11 20:07 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, Florian Westphal
In-Reply-To: <20170410040406.GC1572@madcap2.tricolour.ca>
On Mon, Apr 10, 2017 at 12:04 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-03-21 14:59, Paul Moore wrote:
>> From: Paul Moore <paul@paul-moore.com>
>> The audit subsystem implemented its own buffer cache mechanism which
>> is a bit silly these days when we could use the kmem_cache construct.
>>
>> Some credit is due to Florian Westphal for originally proposing that
>> we remove the audit cache implementation in favor of simple
>> kmalloc()/kfree() calls, but I would rather have a dedicated slab
>> cache to ease debugging and future stats/performance work.
>>
>> Cc: Florian Westphal <fw@strlen.de>
>> Signed-off-by: Paul Moore <paul@paul-moore.com>
>> ---
>> kernel/audit.c | 66 ++++++++++++++------------------------------------------
>> 1 file changed, 17 insertions(+), 49 deletions(-)
>>
>> diff --git a/kernel/audit.c b/kernel/audit.c
>> index b718bf3a73f8..f78cdd75a4d2 100644
>> --- a/kernel/audit.c
>> +++ b/kernel/audit.c
>> @@ -59,6 +59,7 @@
>> #include <linux/mutex.h>
>> #include <linux/gfp.h>
>> #include <linux/pid.h>
>> +#include <linux/slab.h>
>>
>> #include <linux/audit.h>
>>
>> @@ -152,12 +153,7 @@ static atomic_t audit_lost = ATOMIC_INIT(0);
>> /* Hash for inode-based rules */
>> struct list_head audit_inode_hash[AUDIT_INODE_BUCKETS];
>>
>> -/* The audit_freelist is a list of pre-allocated audit buffers (if more
>> - * than AUDIT_MAXFREE are in use, the audit buffer is freed instead of
>> - * being placed on the freelist). */
>> -static DEFINE_SPINLOCK(audit_freelist_lock);
>> -static int audit_freelist_count;
>> -static LIST_HEAD(audit_freelist);
>> +static struct kmem_cache *audit_buffer_cache;
>>
>> /* queue msgs to send via kauditd_task */
>> static struct sk_buff_head audit_queue;
>> @@ -193,17 +189,12 @@ DEFINE_MUTEX(audit_cmd_mutex);
>> * should be at least that large. */
>> #define AUDIT_BUFSIZ 1024
>>
>> -/* AUDIT_MAXFREE is the number of empty audit_buffers we keep on the
>> - * audit_freelist. Doing so eliminates many kmalloc/kfree calls. */
>> -#define AUDIT_MAXFREE (2*NR_CPUS)
>> -
>> /* The audit_buffer is used when formatting an audit record. The caller
>> * locks briefly to get the record off the freelist or to allocate the
>> * buffer, and locks briefly to send the buffer to the netlink layer or
>> * to place it on a transmit queue. Multiple audit_buffers can be in
>> * use simultaneously. */
>> struct audit_buffer {
>> - struct list_head list;
>> struct sk_buff *skb; /* formatted skb ready to send */
>> struct audit_context *ctx; /* NULL or associated context */
>> gfp_t gfp_mask;
>> @@ -1489,6 +1480,10 @@ static int __init audit_init(void)
>> if (audit_initialized == AUDIT_DISABLED)
>> return 0;
>>
>> + audit_buffer_cache = kmem_cache_create("audit_buffer",
>> + sizeof(struct audit_buffer),
>> + 0, SLAB_PANIC, NULL);
>> +
>> memset(&auditd_conn, 0, sizeof(auditd_conn));
>> spin_lock_init(&auditd_conn.lock);
>>
>> @@ -1557,60 +1552,33 @@ __setup("audit_backlog_limit=", audit_backlog_limit_set);
>>
>> static void audit_buffer_free(struct audit_buffer *ab)
>> {
>> - unsigned long flags;
>> -
>> if (!ab)
>> return;
>>
>> kfree_skb(ab->skb);
>> - spin_lock_irqsave(&audit_freelist_lock, flags);
>> - if (audit_freelist_count > AUDIT_MAXFREE)
>> - kfree(ab);
>> - else {
>> - audit_freelist_count++;
>> - list_add(&ab->list, &audit_freelist);
>> - }
>> - spin_unlock_irqrestore(&audit_freelist_lock, flags);
>> + kmem_cache_free(audit_buffer_cache, ab);
>> }
>>
>> -static struct audit_buffer * audit_buffer_alloc(struct audit_context *ctx,
>> - gfp_t gfp_mask, int type)
>> +static struct audit_buffer *audit_buffer_alloc(struct audit_context *ctx,
>> + gfp_t gfp_mask, int type)
>> {
>> - unsigned long flags;
>> - struct audit_buffer *ab = NULL;
>> - struct nlmsghdr *nlh;
>> -
>> - spin_lock_irqsave(&audit_freelist_lock, flags);
>> - if (!list_empty(&audit_freelist)) {
>> - ab = list_entry(audit_freelist.next,
>> - struct audit_buffer, list);
>> - list_del(&ab->list);
>> - --audit_freelist_count;
>> - }
>> - spin_unlock_irqrestore(&audit_freelist_lock, flags);
>> -
>> - if (!ab) {
>> - ab = kmalloc(sizeof(*ab), gfp_mask);
>> - if (!ab)
>> - goto err;
>> - }
>> + struct audit_buffer *ab;
>>
>> - ab->ctx = ctx;
>> - ab->gfp_mask = gfp_mask;
>> + ab = kmem_cache_alloc(audit_buffer_cache, gfp_mask);
>> + if (!ab)
>> + return NULL;
>>
>> ab->skb = nlmsg_new(AUDIT_BUFSIZ, gfp_mask);
>> if (!ab->skb)
>> goto err;
>> + if (!nlmsg_put(ab->skb, 0, 0, type, 0, 0))
>> + goto err;
>>
>> - nlh = nlmsg_put(ab->skb, 0, 0, type, 0, 0);
>> - if (!nlh)
>> - goto out_kfree_skb;
>
> Is there a reason to care about an error returned from nlmsg_put() if
> you aren't going to free the skb that was allocated? If you think
> nlmsg_put() can't fail due to extremely simple calling arguments then
> there is no need to check its return code.
>
> If nlmsg_new() succeeds, it has allocated an skb. If nlmsg_put() fails,
> you free the audit_buffer and the skb is now a memory leak.
>
> Have I read this correctly?
Check my math, but in the patched code if the nlmsg_put() call fails
then we jump to "err" which calls audit_buffer_free() which in turn
calls kfree_skb() on ab->skb so I don't believe we have a memory leak
on error ... I'll hold off on merging this in case I'm missing
something, but I'm pretty sure we're okay here.
> Otherwise, I like the intent of this simplification.
>
>> + ab->ctx = ctx;
>> + ab->gfp_mask = gfp_mask;
>>
>> return ab;
>>
>> -out_kfree_skb:
>> - kfree_skb(ab->skb);
>> - ab->skb = NULL;
>> err:
>> audit_buffer_free(ab);
>> return NULL;
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 0/2] libsepol and checkpolicy: Add ability to expand some attributes in binary policy
From: Jeffrey Vander Stoep @ 2017-04-11 20:06 UTC (permalink / raw)
To: James Carter, selinux
In-Reply-To: <27297f4a-b3ab-128c-7132-41c9add686a2@tycho.nsa.gov>
[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]
Using this patchset with "-G" option - we no longer see preemption on
slowpath policy lookups.
On Tue, Apr 11, 2017 at 12:28 PM James Carter <jwcart2@tycho.nsa.gov> wrote:
On 04/11/2017 01:53 PM, James Carter wrote:
> The number of type attributes included in the binary policy is becomming
a performance issue in some cases.
>
> This patch set more aggressives removes attributes and gives the options
to expand and remove all auto-generated attributes and all attributes with
fewer than a given amount of attributes assigned.
>
> Comparison of the number of attributes remaining in the binary policy
> mls normal android
> org 310 286 255
> old 268 251 130
> max 154 20 17
> min 226 173 119
> def 224 170 80
> gen 221 170 46
> u5 191 112 59
>
> Org - Number of attributes in the CIL policy
> Old - Results without this patch set
> Max - Remove the maximum number of attributes: "-G -X 9999"
> Min - Remove the minimum number of attributes: "-X 0"
> Def - The new defaults for CIL
> Gen - Just removing auto-generated attributes: "-G"
> U5 - Remove attributes with less than five members: "-X 5"
>
>
In case you are interested in sizes:
mls normal android
old 2.1M 2.0M 113K
max 68.3M 63.4M 5041K
min 2.1M 2.0M 122K
def 2.1M 2.0M 115K
gen 2.2M 2.0M 136K
u5 2.2M 2.0M 116K
I would not recommend expanding all attributes.
Jim
> James Carter (2):
> libsepol/cil: Add ability to expand some attributes in binary policy
> secilc: Add options to control the expansion of attributes
>
> libsepol/cil/include/cil/cil.h | 2 +
> libsepol/cil/src/cil.c | 12 ++
> libsepol/cil/src/cil_binary.c | 253
+++++++++++++++++++++++++++----------
> libsepol/cil/src/cil_internal.h | 7 +-
> libsepol/cil/src/cil_post.c | 32 +++--
> libsepol/cil/src/cil_resolve_ast.c | 25 ++--
> libsepol/src/libsepol.map.in | 2 +
> secilc/secil2conf.c | 2 +
> secilc/secilc.8.xml | 10 ++
> secilc/secilc.c | 31 ++++-
> 10 files changed, 275 insertions(+), 101 deletions(-)
>
--
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency
_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
To get help, send an email containing "help" to
Selinux-request@tycho.nsa.gov.
[-- Attachment #2: Type: text/html, Size: 5146 bytes --]
^ permalink raw reply
* Re: [PATCH v5 3/8] convert: Split start_multi_file_filter into two separate functions
From: Jeff King @ 2017-04-11 20:05 UTC (permalink / raw)
To: Lars Schneider; +Cc: Ben Peart, git, gitster, benpeart, christian.couder
In-Reply-To: <629B2192-FD64-422E-9361-C182303582DC@gmail.com>
On Tue, Apr 11, 2017 at 10:01:02PM +0200, Lars Schneider wrote:
> > If you initialize errno to 0 right before a syscall, then yes, you can
> > trust it without checking the return value of the syscall. I wouldn't
> > trust it before calling more complicated functions, though. Not even
> > xwrite(), which may see EINTR and keep going (which is OK for checking
> > for EPIPE, but not checking generally for errno values).
>
> Should we remove all the errno checks here as we don't have any direct
> "write" etc syscalls anyways then?
Yeah, you should be trusting the return value from the various
sub-functions. Usually you'd check "errno == EPIPE" only when you saw an
error return but you want to _ignore_ EPIPE. This is what
filter_buffer_or_fd() is doing.
But the code here is the opposite case. It definitely wants to treat
EPIPE as an error. But that should be happening already because any
EPIPE we get would come with an error-return from one of the
packet_write() functions.
So I would say that "err || errno == EPIPE" here can just become "err",
and ditto in apply_multi_file_filter().
-Peff
^ permalink raw reply
* Re: [PATCH] blkfront: add uevent for size change
From: Konrad Rzeszutek Wilk @ 2017-04-11 20:04 UTC (permalink / raw)
To: Marc Olson
Cc: xen-devel, Boris Ostrovsky, David Vrabel, linux-kernel,
Roger Pau Monné
In-Reply-To: <20170411192403.GA26778@amazon.com>
On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote:
> When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
> notify the guest about the change. This allows for custom udev rules, such
> as automatically resizing a filesystem, when an event occurs.
Looks pretty reasonable.
Could you confirm what the udevadm --monitor --kernel --udev emits when this happens?
Thanks!
>
> Signed-off-by: Marc Olson <marcolso@amazon.com>
> ---
> drivers/block/xen-blkfront.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2fee2ee..66abf9c 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1996,6 +1996,7 @@ static void blkfront_connect(struct blkfront_info *info)
> unsigned long sector_size;
> unsigned int physical_sector_size;
> unsigned int binfo;
> + char *envp[] = { "RESIZE=1", NULL };
> int err;
>
> switch (info->connected) {
> @@ -2012,6 +2013,8 @@ static void blkfront_connect(struct blkfront_info *info)
> sectors);
> set_capacity(info->gd, sectors);
> revalidate_disk(info->gd);
> + kobject_uevent_env(&disk_to_dev(info->gd)->kobj,
> + KOBJ_CHANGE, envp);
>
> return;
> case BLKIF_STATE_SUSPENDED:
> --
> 2.7.4
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] blkfront: add uevent for size change
From: Konrad Rzeszutek Wilk @ 2017-04-11 20:04 UTC (permalink / raw)
To: Marc Olson
Cc: xen-devel, Roger Pau Monné, Boris Ostrovsky, David Vrabel,
linux-kernel
In-Reply-To: <20170411192403.GA26778@amazon.com>
On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote:
> When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
> notify the guest about the change. This allows for custom udev rules, such
> as automatically resizing a filesystem, when an event occurs.
Looks pretty reasonable.
Could you confirm what the udevadm --monitor --kernel --udev emits when this happens?
Thanks!
>
> Signed-off-by: Marc Olson <marcolso@amazon.com>
> ---
> drivers/block/xen-blkfront.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2fee2ee..66abf9c 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1996,6 +1996,7 @@ static void blkfront_connect(struct blkfront_info *info)
> unsigned long sector_size;
> unsigned int physical_sector_size;
> unsigned int binfo;
> + char *envp[] = { "RESIZE=1", NULL };
> int err;
>
> switch (info->connected) {
> @@ -2012,6 +2013,8 @@ static void blkfront_connect(struct blkfront_info *info)
> sectors);
> set_capacity(info->gd, sectors);
> revalidate_disk(info->gd);
> + kobject_uevent_env(&disk_to_dev(info->gd)->kobj,
> + KOBJ_CHANGE, envp);
>
> return;
> case BLKIF_STATE_SUSPENDED:
> --
> 2.7.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.