ux-mm/20190826104144.GA7849@linux/T/#u
FWIW, tested again with these patches in the ppc64 box and they work.
I see that you added my Tested-by in the last patch but in any case:
Tested-by: Aristeu Rozanski
--
Aristeu
On Thu, Sep 17, 2020 at 10:10:44AM +0200, Oscar Salvador wrote:
> Aristeu Rozanski reported that some hwpoison tests
> were returning -EBUSY while before the rework they succeed [1] [2].
>
> The root case is that during a rebase, the call to page_handle_poison was
> setting hugep
On Thu, Sep 17, 2020 at 10:10:45AM +0200, Oscar Salvador wrote:
> Aristeu Rozanski reported that a customer test case started
> to report -EBUSY after the hwpoison report patchset.
>
> There is a race window between spotting a free page and taking it off
> its buddy freelist, so i
Hi Oscar,
On Wed, Sep 16, 2020 at 09:27:02AM +0200, Oscar Salvador wrote:
> Could you please re-run the tests with the below patch applied, and
> attached then the logs here?
here it is:
(removed previous dump_page() calls for other pages that didn't fail)
[ 109.709342] Soft offlining pfn 0x3fb
Hi Oscar,
On Wed, Sep 16, 2020 at 04:09:30PM +0200, Oscar Salvador wrote:
> On Wed, Sep 16, 2020 at 09:53:58AM -0400, Aristeu Rozanski wrote:
> Can you try the other patch I posted in response to Naoya?
Same thing:
[ 369.195056] Soft offlining pfn 0x3fb5bf at process virtual a
On Wed, Sep 16, 2020 at 06:34:52PM +0200, osalva...@suse.de wrote:
> Fat fingers, sorry:
>
> Ok, this is something different.
> The race you saw previously is kinda normal as there is a race window
> between spotting a freepage and taking it off the buddy freelists.
> The retry patch should help
Hi Oscar, Naoya,
On Mon, Sep 14, 2020 at 12:15:54PM +0200, Oscar Salvador wrote:
> The important bit of this patchset is patch#1, which is a fix to take off
> HWPoison pages off a buddy freelist since it can lead us to having HWPoison
> pages back in the game without no one noticing it.
> So fix i
On Thu, Aug 13, 2020 at 04:55:50PM +0300, Boris Petkov wrote:
> On August 13, 2020 4:44:06 PM GMT+03:00, Aristeu Rozanski
> wrote:
> >We tested this inside in machines having this issue and it works.
> >Patch looks good to me.
> >
> >Acked-by: Aristeu Rozanski
&g
edac_dbg(0, "ie31200 init fail\n");
> + pci_rc = -ENODEV;
> + goto fail1;
> + }
> + }
> + return 0;
> +
> +fail1:
> + pci_unregister_driver(&ie31200_driver);
> +fail0:
> + pci_dev_put(mci_pdev);
> +
> + return pci_rc;
> }
>
> static void __exit ie31200_exit(void)
> {
> edac_dbg(3, "MC:\n");
> pci_unregister_driver(&ie31200_driver);
> + if (!ie31200_registered)
> + ie31200_remove_one(mci_pdev);
> }
>
> module_init(ie31200_init);
We tested this inside in machines having this issue and it works.
Patch looks good to me.
Acked-by: Aristeu Rozanski
--
Aristeu
On Tue, Sep 25, 2018 at 09:34:49AM -0500, Justin Ernst wrote:
> We observe an oops in the skx_edac module during boot.
That's happening also on sb_edac too and the oops comes from memory corruption
after trying to load the module several times during boot.
--
Aristeu
fixes it.
Signed-off-by: Aristeu Rozanski
Cc: "Luis R. Rodriguez"
Cc: Kees Cook
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 4ac9b9a..243f277 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2486,7 +2486,8 @@ static int do_proc_dointvec_minmax_conv(bool *negp,
un
On Wed, Jul 19, 2017 at 06:22:04PM +0200, Borislav Petkov wrote:
> On Wed, Jul 19, 2017 at 04:10:07PM +, Kani, Toshimitsu wrote:
> > I do prefer to avoid any white / black listing. But I do not see how
> > it solves the buggy DMI/SMBIOS info as an example of firmware bugs we
> > may have to de
participants[channel] = 1;
> break;
I can confirm this fixes the issues I've seen with the upstream driver.
Acked-by: Aristeu Rozanski
--
Aristeu
Hi Michal,
On Tue, Oct 27, 2015 at 05:20:47PM +0100, Michal Hocko wrote:
> Yes this is a mess. But I think it is worth cleaning up.
> dump_stack_print_info (arch independent) has a log level parameter.
> show_stack_log_lvl (x86) has a loglevel parameter which is unused.
>
> I haven't checked other
Hi Michal,
On Tue, Oct 27, 2015 at 09:09:21AM +0100, Michal Hocko wrote:
> On Mon 26-10-15 13:40:49, Aristeu Rozanski wrote:
> > Hi Michal,
> > On Mon, Oct 26, 2015 at 06:20:12PM +0100, Michal Hocko wrote:
> [...]
> > > Would it make more sense to distinguish
On Mon, Oct 26, 2015 at 12:01:11PM -0400, Johannes Weiner wrote:
> I think this makes sense.
>
> The high volume log output is not just annoying, we have also had
> reports from people whose machines locked up as they tried to log
> hundreds of containers through a low-bandwidth serial console.
>
Hi Michal,
On Mon, Oct 26, 2015 at 06:20:12PM +0100, Michal Hocko wrote:
> I can see why you want to reduce the amount of information, I guess you
> have tried to reduce the loglevel but this hasn't helped because
> dump_stack uses default log level which is too low to be usable, right?
> Or are th
log
output for each situation is useful.
This patch adds a sysctl to allow disabling dump_stack() during an OOM while
keeping the default to behave the same way it behaves today.
Cc: Greg Thelen
Cc: Johannes Weiner
Cc: linux...@kvack.org
Cc: cgro...@vger.kernel.org
Signed-off-by: Ariste
+ * IPC_RMID as we hold sma->sem_perm.lock */
> list_del_rcu(&un->list_proc);
> - spin_unlock(&ulp->lock);
>
> /* perform adjustments registered in un */
> for (i = 0; i < sma->sem_nsems; i++) {
module sbridge_edac.c controller Sandy Bridge
> Socket#0: DEV :3f:0e.0 (POLLED)
> EDAC MC1: Giving out device to module sbridge_edac.c controller Sandy Bridge
> Socket#1: DEV :7f:0e.0 (POLLED)
Acked-by: Aristeu Rozanski
>
> Signed-off-by: Seth Jennings
> --
Hi Jim, Lukasz,
On Tue, Jun 09, 2015 at 01:43:11PM +0200, lukasz.anaczkow...@intel.com wrote:
> @@ -273,6 +270,10 @@ struct sbridge_info {
> u64 (*get_tolm)(struct sbridge_pvt *pvt);
> u64 (*get_tohm)(struct sbridge_pvt *pvt);
> u64 (*rir_limit)
Hi Steve,
On Tue, May 05, 2015 at 10:22:32AM -0400, Steve Grubb wrote:
> The requirements for auditing of containers should be derived from VPP. In
> it,
> it asks for selectable auditing, selective audit, and selective audit review.
> What this means is that we need the container and all its ch
Hi Peter,
On Wed, Feb 18, 2015 at 10:40:10AM -0500, Peter Hurley wrote:
> The child is not receiving SIGHUP because /dev/ttyS0 was not set as the
> controlling terminal by ioctl(TIOCSCTTY), which is failing (probably
> with errno == EPERM). You need to check the return value and errno.
>
> To set
Hi Peter,
On Tue, Feb 17, 2015 at 05:35:10PM -0500, Peter Hurley wrote:
> I realize that. But hanging up the tty that is /dev/console only affects
> open descriptors that are not /dev/console.
>
> So readers using the /dev/ttyS0 file descriptor will see a hungup fops,
> but readers using /dev/cons
Hi Peter,
On Tue, Feb 17, 2015 at 04:28:30PM -0500, Peter Hurley wrote:
> On 02/17/2015 04:06 PM, Aristeu Rozanski wrote:
> > If the console has a canonical reader and the respective tty hangs up,
> > it'll waste a wake up and will never release the last ldisc reference so
&g
[ 240.450543] [] SyS_ioctl+0x81/0xa0
[ 240.450921] [] system_call_fastpath+0x16/0x1b
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Peter Hurley
Signed-off-by: Aristeu Rozanski
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 0f74945..4fb909d 100644
7 @@ static int sbridge_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> goto fail1;
> }
>
> - sbridge_printk(KERN_INFO, "Driver loaded.\n");
> + sbridge_printk(KERN_INFO, "%s\n", SBRIDGE_REVISION);
>
This patch adds section .rodata comparison in order to detect string
constant changes.
Cc: Josh Triplett
Signed-off-by: Aristeu Rozanski
diff --git a/scripts/bloat-o-meter b/scripts/bloat-o-meter
index 23e78dc..cee812a 100755
--- a/scripts/bloat-o-meter
+++ b/scripts/bloat-o-meter
@@ -26,40
On Wed, Jan 07, 2015 at 03:43:06PM +0800, Huang Ying wrote:
> Do not find memory modules' part number in EFI menu. Some information
> about memory is:
>
> 2133MT/s Micron DRx8 8GB UDIMM
Based on a quick search it doesn't look it's ECC memory :(
If/when you have a chance to open this box, could y
Hi,
On Fri, Dec 19, 2014 at 01:26:59PM +0800, Huang Ying wrote:
> In fact, I am not complaining :-), just FYI. As I said, this may be a
> expected behavior because this is a Haswell machine and the Haswell
> support was added in this patch.
>
> > From the above, what looks weird, from EDAC driver
On Tue, Dec 02, 2014 at 09:41:58AM -0800, Tony Luck wrote:
> Code will always think there are 16 banks because of a typo
>
> Reported-by: Misha
> Signed-off-by: Tony Luck
> ---
>
> Not sure if Misha is shy, or just busy. But my attempt to get
> them to post their own patch didn't work
>
> driv
ELL_IMC_HA0_TAD2, 1) },
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD3, 1) },
You are marking TAD2 and TAD3 as optional here, but
> + for (i = 0; i < NUM_CHANNELS; i++) {
> + if (!pvt->pci_tad[i])
> + goto enodev;
> + }
It'
On Thu, Nov 06, 2014 at 01:44:54PM -0800, Dave Hansen wrote:
> On 11/06/2014 01:33 PM, Dave Hansen wrote:
> > On 11/06/2014 01:27 PM, Aristeu Rozanski wrote:
> >> +config FLEX_ARRAY
> >> + bool "Flexible array"
> >> + default n
> >> +
On Thu, Nov 06, 2014 at 01:32:03PM -0800, Joe Perches wrote:
> why not default n ? (and in the other patch)
As I see, stuff in lib/ can be available by default unless you
specifically ask to disable it. It doesn't really matter in these
patches since most of the time the options will be selected i
From: Aristeu Rozanski
rhashtable currently is built unconditionally:
textdata bss dec hex filename
915820085264 16430402e lib/rhashtable.o
915820085264 16430402e (TOTALS)
and it's used by netlink (which currently can
From: Aristeu Rozanski
halfmd4 currently is built unconditionally:
textdata bss dec hex filename
801 176 8 985 3d9 lib/halfmd4.o
801 176 8 985 3d9 (TOTALS)
and it's used by ext3 and ext4. This patch is usefu
From: Aristeu Rozanski
flex_array currently is built unconditionally:
textdata bss dec hex filename
22941008156848701306 lib/flex_array.o
22941008156848701306 (TOTALS)
and it's used by procfs, selinux and openvswitch.
e it to ALLOW_DEV_COREDUMP to better capture its semantics.
Sounds much better!
Acked-by: Aristeu Rozanski
>
> Signed-off-by: Johannes Berg
> ---
> drivers/base/Kconfig | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/Kcon
x27;n' (as in allnconfig or tinyconfig) will effectively disable device
coredump.
Cc: Greg Kroah-Hartman
Cc: Josh Triplett
Cc: Johannes Berg
Reviewed-by: Josh Triplett
Signed-off-by: Aristeu Rozanski
---
drivers/base/Kconfig | 19 +++
1 file changed, 11 insertions(+), 8 del
option to ENABLE_DEV_COREDUMP and setting it to
'n' (as in allnconfig or tinyconfig) will effectively disable device
coredump.
Cc: Greg Kroah-Hartman
Cc: Josh Triplett
Cc: Johannes Berg
Reviewed-by: Josh Triplett
Signed-off-by: Aristeu Rozanski
diff --git a/drivers/base/Kconfig b/drivers/base/K
On Thu, Oct 16, 2014 at 12:24:05PM +0200, Josh Triplett wrote:
> I agree; I'm just saying blame me rather than Aristeu. :)
Thanks Josh, but I should have used my brain and realized it's just the
Kconfig. Will resubmit it shortly.
--
Aristeu
--
To unsubscribe from this list: send the line "unsub
x27;n' (as in allnconfig or tinyconfig) will effectively disable device
coredump.
Cc: Greg Kroah-Hartman
Cc: Josh Triplett
Reviewed-by: Josh Triplett
Signed-off-by: Aristeu Rozanski
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 134f763..63a5702 100644
--- a/drivers/bas
On Thu, Sep 11, 2014 at 05:51:31PM +0800, Chen Hanxiao wrote:
> Use marco instead of magic number
> for max user namespace level.
patch is ok, but you might want to do s/marco/macro/
--
Aristeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
nnel is not specified. edac_mc_handle_error() sets the channel to -1
> internally after the error message anyway, so this commit should have no
> effect other than avoiding the INTERNAL ERROR message when the channel
> is not specified.
>
> Signed-off-by: Seth Jennings
> Cc: A
i_device_id sbridge_pci_tbl[] = {
> - {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA)},
> + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA)},
> {0,}
C_TAD3 0x3cad /* 15.5 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO0x3cb8 /* 17.0 */
> #define PCI_DEVICE_ID_INTEL_JAKETOWN_UBOX0x3ce0
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD0 0x3cf4 /* 12.6 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_BR 0x3cf5 /* 13.6 */
>
Hi Richard,
On Wed, Aug 20, 2014 at 09:09:33PM -0400, Richard Guy Briggs wrote:
> Is there a way to link serial numbers of namespaces involved in migration of a
> container to another kernel? It sounds like what is needed is a part of a
> mangement application that is able to pull the audit record
sing track of this and didn't send
earlier.
Signed-off-by: Aristeu Rozanski
> drivers/input/tablet/wacom_sys.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/input/tablet/wacom_sys.c
> b/drivers/input/tablet/wacom_sys.c
> index 7087b33..319a3ff 1006
f-by: Tejun Heo
> Cc: Aristeu Rozanski
> Cc: Serge Hallyn
> ---
> security/device_cgroup.c | 19 ++-
> 1 file changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 75b4b18..22de334 100644
&
> only care about children which are visible to userland.
>
> This patch converts has_children() to use css_next_child() instead.
> The subtle incorrectness is noted and will be dealt with later.
>
> Signed-off-by: Tejun Heo
> Cc: Aristeu Rozanski
> Cc: Serge Hally
_BUFFER_SIZE in cgroup_freezer.c.
>
> This patch doesn't introduce any visible behavior changes.
>
> Signed-off-by: Tejun Heo
> Cc: Vivek Goyal
> Cc: Jens Axboe
> Cc: Li Zefan
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Aristeu Rozanski
On Wed, Apr 09, 2014 at 01:35:52PM +0200, Borislav Petkov wrote:
> Btw, remind me again why this isn't part of the sb_edac? AFAICT, the
> e3-12xx thing is a Sandybridge, right?
>
> Why not put it into sb_edac - it is small enough and if you're lucky,
> you might even share functionality?
By quick
On Mon, Feb 17, 2014 at 01:10:23PM +0800, Jiang Liu wrote:
> On a system with four Intel processor, it generates too many messages
> "EDAC sbridge: Seeking for: dev 1d.3 PCI ID ". And it doesn't
> give many useful information for normal users, so change log level
> from INFO to DEBUG.
>
> Sign
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -58,11 +58,9 @@ static inline struct dev_cgroup *css_to_devcgroup(struct
> cgroup_subsys_state *s)
>
> static inline struct dev_cgroup *task_devcgroup(struct task_struct *task)
> {
> - return css_to_devcgroup(task_css(t
On Wed, Oct 30, 2013 at 11:21:49AM -0600, Bjorn Helgaas wrote:
> On Wed, Oct 30, 2013 at 11:19 AM, Mauro Carvalho Chehab
> wrote:
> > Em Wed, 30 Oct 2013 17:40:20 +0100
> > Borislav Petkov escreveu:
> >
> >> On Wed, Oct 30, 2013 at 12:26:55PM -0400, Aristeu Ro
This is in preparation for Ivy Bridge support
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index fcd9c66..0bafe0a 100644
--- a/drivers
This is in preparation for Ivy Bridge support
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c | 66 +--
1 files changed, 30 insertions(+), 36 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index dbd99d3
This is needed to allow separated PCI id tables for Sandy Bridge and Ivy
Bridge.
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index
Whenever the extended error reporting is active, multiple MCEs will be
generated for the same event, which will lead to multiple repeated
errors to be reported. So check ADDRV and only decode the error if the
MCE address is valid.
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c
This is in preparation of Ivy Bridge support.
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 4cdd948..466c313 100644
--- a/drivers/edac/sb_edac.c
This is in preparation for Ivy Bridge support
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 0bafe0a..dbd99d3 100644
--- a/drivers/edac
Ivy Bridge has more than one, so rename pci_br to pci_br0
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 3e4837f..eb6c9d4 100644
--- a/drivers/edac
Since Ivy Bridge memory controller is very similar to Sandy Bridge, it's
wiser to modify sb_edac to support both instead of creating another
driver.
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c | 447
1 files changed
This is in preparation for Ivy Bridge support
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 3e07c28..2e977b9 100644
--- a/drivers/edac/sb_edac.c
+++ b
This is preparation of Ivy Bridge support.
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index eb6c9d4..fcd9c66 100644
--- a/drivers/edac/sb_edac.c
According to the comment, it should be done before submitting upstream.
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c | 21 ++---
include/linux/pci_ids.h | 11 +++
2 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/edac/sb_edac.c b
This is in preparation for the Ivy Bridge support.
Signed-off-by: Aristeu Rozanski
---
drivers/edac/sb_edac.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 466c313..3e4837f 100644
--- a/drivers
dling before or after, it's moved inside the
> iteration. If not, if (pos == origin) continue; is added. Some
> conversions add extra reference get/put around origin handling by
> consolidating origin handling and the rest. While the extra ref
> operations aren't strictly
ed.
>
> * devices: cgroup_to_devcgroup() is no longer used. Removed.
Acked-by: Aristeu Rozanski
--
Aristeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
any user left. Removed.
>
> * hugetlb: hugetlb_cgroup_form_cgroup() doesn't have any user left.
> Removed.
>
> * net_cls: cgrp_cls_state() doesn't have any user left. Removed.
Also looks good on devcg part
Acked-by: Aristeu Rozanski
--
Aristeu
--
To unsubscrib
nel/cgroup.c::offline_css(), unnecessary open coded css
> dereference is replaced with local variable access.
>
> This patch shouldn't cause any behavior differences.
looks fine on device_cgroup.c bit
Acked-by: Aristeu Rozanski
--
Aristeu
--
To unsubscribe from this list: send the l
On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote:
> Gao feng writes:
>
> > On 06/20/2013 11:02 AM, Gao feng wrote:
> >> If we don't tie audit to user namespace, there is still one problem.
> >
> > One more problem. some audit messages are generated by some net subsystem
> > such
On Wed, Jun 19, 2013 at 09:53:32AM +0800, Gao feng wrote:
> This patchset is first part of namespace support for audit.
> in this patchset, the mainly resources of audit system have
> been isolated. the audit filter, rules havn't been isolated
> now. It will be implemented in Part2. We finished the
On Tue, May 14, 2013 at 10:05:39AM -0500, Serge Hallyn wrote:
> so now that the device cgroup properly respects hierarchy, not allowing
> a cgroup to be given greater permission than its parent, should we consider
> relaxing the capability checks?
>
> There are two capable(CAP_SYS_ADMIN) checks in
On Tue, May 07, 2013 at 10:20:30AM +0800, Gao feng wrote:
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 684599b..33e6584 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -441,7 +441,8 @@ extern int audit_filter_type(int type);
> extern int audit_recei
On Tue, Apr 16, 2013 at 04:07:25PM -0500, Serge Hallyn wrote:
> Quoting Aristeu Rozanski (a...@redhat.com):
> > On Tue, Apr 16, 2013 at 11:24:55PM +0300, Rami Rosen wrote:
> > > In devcgroup_css_alloc(), there is no longer need for parent_cgroup.
> > > bd2953ebbb(&quo
On Tue, Apr 16, 2013 at 11:24:55PM +0300, Rami Rosen wrote:
> In devcgroup_css_alloc(), there is no longer need for parent_cgroup.
> bd2953ebbb("devcg: propagate local changes down the hierarchy") made
> the variable parent_cgroup redundant. This patch removes parent_cgroup
> from devcgroup_css_all
ted proper hierarchy support. Remove the broken tag.
>
> Signed-off-by: Tejun Heo
> Cc: Aristeu Rozanski
> ---
> Applying to cgroup/for-3.10.
looks good, thanks Tejun
Acked-by: Aristeu Rozanski
--
Aristeu
--
To unsubscribe from this list: send the line "unsubscribe
Hi Tejun,
On Tue, Feb 19, 2013 at 04:20:16PM -0500, Aristeu Rozanski wrote:
> On Tue, Feb 19, 2013 at 09:12:08PM +, Serge E. Hallyn wrote:
> > Quoting Aristeu Rozanski (a...@redhat.com):
> > > + } else {
> > > + /*
> > > +
On Tue, Feb 19, 2013 at 09:12:08PM +, Serge E. Hallyn wrote:
> Quoting Aristeu Rozanski (a...@redhat.com):
> > + } else {
> > + /*
> > +* in the other possible cases:
> > +* root'
take devcgroup_mutex before walking the
tree while walking the tree itself is protected by rcu lock.
Acked-by: Tejun Heo
Acked-by: Serge Hallyn
Cc: Tejun Heo
Cc: Serge Hallyn
Signed-off-by: Aristeu Rozanski
---
security/device_cgroup.c | 59 +--
1
In order to make the next patch more clear, expand may_access() logic.
v2: may_access() returns bool now
Acked-by: Tejun Heo
Acked-by: Serge Hallyn
Cc: Tejun Heo
Cc: Serge Hallyn
Signed-off-by: Aristeu Rozanski
---
security/device_cgroup.c | 21 -
1 file changed, 12
d by Tejun Heo
- instead of keeping the local settings that won't apply anymore, remove them
Cc: Tejun Heo
Cc: Serge Hallyn
Signed-off-by: Aristeu Rozanski
---
Documentation/cgroups/devices.txt | 70 ++-
security/device_cgroup.c | 139 +++
patch description
- rebased on top of a new patch to expand the may_access() logic to make it
more clear
- fixed argument description order in may_access()
Acked-by: Tejun Heo
Acked-by: Serge Hallyn
Cc: Tejun Heo
Cc: Serge Hallyn
Signed-off-by: Aristeu Rozanski
---
security/device_cgroup.c |
em around.
Cc: Tejun Heo
Cc: Serge Hallyn
Signed-off-by: Aristeu Rozanski
--
Aristeu
--
To unsubscribe from
On Mon, Feb 11, 2013 at 06:52:39PM +, Serge E. Hallyn wrote:
> > getting rid of local settings would buy more simplicity
>
> (Not sure which you mean here by 'getting rid of local settings')
no local.{behavior,exceptions}, which still would allow behavior
propagation, but simply wouldn't keep
On Mon, Feb 11, 2013 at 05:42:59PM +, Serge E. Hallyn wrote:
> Note I said only forbid behavior changes - not exception changes - to
> cgroups with children.
that won't do much. behavior change is the simplest: if you change a
behavior, you wipe the local exceptions unless the special (deny, d
On Sat, Feb 09, 2013 at 03:53:57AM +, Serge E. Hallyn wrote:
> Quoting Aristeu Rozanski (a...@redhat.com):
>
> Thanks, Aristeu. I'm sorry it feels like I'm just trying to give you a
> hard time, I'm really not :)
no worries on that, it's important this is
On Sat, Feb 09, 2013 at 04:04:02AM +, Serge E. Hallyn wrote:
> Quoting Aristeu Rozanski (a...@redhat.com):
> > devcg: propagate local changes down the hierarchy
> >
> > This patch makes all changes propagate down in hierarchy respecting when
> > po
by Tejun Heo
- instead of keeping the local settings that won't apply anymore, remove them
Acked-by: Tejun Heo
Cc: Tejun Heo
Cc: Serge Hallyn
Signed-off-by: Aristeu Rozanski
---
Documentation/cgroups/devices.txt | 67 +++
security/device_cgroup.c | 228 +
On Sat, Feb 02, 2013 at 04:20:52PM +, Serge E. Hallyn wrote:
> Quoting Aristeu Rozanski (a...@redhat.com):
> > +static int propagate_exception(struct dev_cgroup *devcg_root)
> > +{
> > + struct cgroup *root = devcg_root->css.cgroup;
> > + struct de
On Sat, Feb 02, 2013 at 04:13:41PM +, Serge E. Hallyn wrote:
> Quoting Aristeu Rozanski (a...@redhat.com):
> > +static int propagate_behavior(struct dev_cgroup *devcg_root)
> > +{
> > + struct cgroup *root = devcg_root->css.cgroup;
> > + struct dev_cgroup *par
online/css_offline changes to a new patch
- use cgroup_for_each_descendant_pre() instead of own descendant walk
- move exception_copy rework to a separared patch
- move exception_clean rework to a separated patch
v2:
- instead of keeping the local settings that won't apply anymore, remo
Hi Serge,
On Thu, Jan 31, 2013 at 04:38:39AM +, Serge E. Hallyn wrote:
> > @@ -610,9 +770,14 @@case '\0':
> > */
> > if (devcgroup->behavior == DEVCG_DEFAULT_ALLOW) {
> > dev_exception_rm(devcgroup, &ex);
> > - retur
On Thu, Jan 31, 2013 at 04:19:32AM +, Serge E. Hallyn wrote:
> Quoting a...@redhat.com (a...@redhat.com):
> > +/**
> > + * propagate_behavior - propagates a change in the behavior down in
> > hierarchy
> > + * @devcg_root: device cgroup that changed behavior
> > + *
> > + * returns: 0 in case
On Wed, Jan 30, 2013 at 12:50:38PM -0800, Tejun Heo wrote:
> On Wed, Jan 30, 2013 at 12:49 PM, Aristeu Rozanski > that's not
> intentional. thanks for catching this
> >
> > Tejun, you want me to resubmit the whole series or just the next patch
> > (where I was suppo
On Wed, Jan 30, 2013 at 08:47:30PM +, Serge E. Hallyn wrote:
> Quoting a...@redhat.com (a...@redhat.com):
> > -
> > - if (rc)
> > - return rc;
>
> Was this intentional?
>
> I see that you next add
>
> rc = propagate_behavior(devcgroup);
>
>
On Wed, Jan 30, 2013 at 05:41:40PM +, Serge E. Hallyn wrote:
> Quoting a...@redhat.com (a...@redhat.com):
> > In the following patches, device_cgroup structure will have two sets of
> > behavior and exceptions list (actual one, another with the local settings)
> > so rework the functions to use
On Tue, Jan 29, 2013 at 12:35:00PM -0800, Tejun Heo wrote:
> Generally looks good to me although I haven't really delved into the
> behavior (you're gonna be there for the fallouts, right?). Just some
> minor comments.
yes, I'll.
> > +static int propagate_behavior(struct dev_cgroup *devcg_root)
t; > so rework the functions to use exception list, not a device_cgroup.
> >
> > Cc: Tejun Heo
> > Cc: Serge Hallyn
> > Signed-off-by: Aristeu Rozanski
>
> Acked-by: Tejun Heo
>
> Can you please keep acks across postings? That makes it a bit easier
>
1 - 100 of 195 matches
Mail list logo
