Re: [PATCH v7 00/14] HWPOISON: soft offline rework
Hi Oscar, On Tue, Sep 22, 2020 at 03:56:36PM +0200, Oscar Salvador wrote: > This patchset is the latest version of soft offline rework patchset > targetted for v5.9. > > This patchset fixes a couple of issues that the patchset Naoya > sent [1] contained due to rebasing problems and a misunterdansting. > > Main focus of this series is to stabilize soft offline. Historically soft > offlined pages have suffered from racy conditions because PageHWPoison is > used to a little too aggressively, which (directly or indirectly) invades > other mm code which cares little about hwpoison. This results in unexpected > behavior or kernel panic, which is very far from soft offline's "do not > disturb userspace or other kernel component" policy. > An example of this can be found here [2]. > > Along with several cleanups, this code refactors and changes the way soft > offline work. > Main point of this change set is to contain target page "via buddy allocator" > or in migrating path. > For ther former we first free the target page as we do for normal pages, and > once it has reached buddy and it has been taken off the freelists, we flag it > as HWpoison. > For the latter we never get to release the page in unmap_and_move, so > the page is under our control and we can handle it in hwpoison code. > > [1] https://patchwork.kernel.org/cover/11704083/ > [2] https://lore.kernel.org/linux-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
Re: [PATCH v4 2/7] mm,hwpoison: Do not set hugepage_or_freepage unconditionally
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 hugepage_or_freepage = true unconditionally from __soft_offline_page. > > Aristeu said that after this fix, everything works. > > [1] https://patchwork.kernel.org/comment/23617301/ > [2] https://patchwork.kernel.org/comment/23619535/ > > Signed-off-by: Oscar Salvador > Reported-by: Aristeu Rozanski Tested-by: Aristeu Rozanski -- Aristeu
Re: [PATCH v4 3/7] mm,hwpoison: Try to narrow window race for free pages
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 it might be that by the time we try to take it off, > the page has been already allocated. > > This patch tries to handle such race window by trying to handle the new > type of page again if the page was allocated under us. > > After this patch, Aristeu said the test cases work properly. > > Signed-off-by: Oscar Salvador > Reported-by: Aristeu Rozanski Tested-by: Aristeu Rozanski -- Aristeu
Re: [PATCH v3 0/5] HWpoison: further fixes and cleanups
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 0x3fb526 at process virtual address 0x7ffc7a18 [ 109.716969] page:f367dde5 refcount:1 mapcount:0 mapping: index:0x7ffc7a18 pfn:0x3fb526 [ 109.716978] anon flags: 0x380008000e(referenced|uptodate|dirty|swapbacked) [ 109.716988] raw: 00380008000e 5deadbeef100 5deadbeef122 c03fcd56d839 [ 109.716997] raw: 7ffc7a18 0001 c03fd42f5000 [ 109.717005] page dumped because: page_handle_poison [ 109.717011] page->mem_cgroup:c03fd42f5000 [ 109.725882] page_handle_poison: hugepage_or_freepage failed [ 109.725885] __soft_offline_page: page_handle_poison -EBUSY [ 109.725898] page:f367dde5 refcount:3 mapcount:0 mapping:b43d73e6 index:0x58 pfn:0x3fb526 [ 109.725951] aops:xfs_address_space_operations [xfs] ino:49f9c5f dentry name:"messages" [ 109.725958] flags: 0x382008(dirty|private) [ 109.725963] raw: 00382008 5deadbeef100 5deadbeef122 c03fb8b7eea8 [ 109.725969] raw: 0058 c03fdd94eb20 0003 c03fd3c42000 [ 109.725975] page dumped because: __soft_offline_page after migrate [ 109.725980] page->mem_cgroup:c03fd3c42000 -- Aristeu
Re: [PATCH v3 0/5] HWpoison: further fixes and cleanups
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 address 0x7ffc8435 [ 369.195073] page:2bb131e4 refcount:1 mapcount:0 mapping: index:0x7ffc8435 pfn:0x3fb5bf [ 369.195080] anon flags: 0x380008000e(referenced|uptodate|dirty|swapbacked) [ 369.202131] raw: 00380008000e 5deadbeef100 5deadbeef122 c03fda1c7431 [ 369.202137] raw: 7ffc8435 0001 c03fd63af000 [ 369.202141] page dumped because: page_handle_poison [ 369.202145] page->mem_cgroup:c03fd63af000 [ 369.215055] page_handle_poison: hugepage_or_freepage failed�n [ 369.215057] __soft_offline_page: page_handle_poison -EBUSY [ 369.215068] page:2bb131e4 refcount:3 mapcount:0 mapping:f6ca3f32 index:0x5c pfn:0x3fb5bf [ 369.215110] aops:xfs_address_space_operations [xfs] ino:49f9c5f dentry name:"messages" [ 369.215117] flags: 0x382008(dirty|private) [ 369.215121] raw: 00382008 5deadbeef100 5deadbeef122 c03fadd3daa8 [ 369.215127] raw: 005c c03fd9497c20 0003 c03fd1143000 [ 369.215132] page dumped because: __soft_offline_page after migrate [ 369.215136] page->mem_cgroup:c03fd1143000 -- Aristeu
Re: [PATCH v3 0/5] HWpoison: further fixes and cleanups
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 there. > > The issue you are seeing right here is due to the call to > page_handle_poison in __soft_offline_page being wrong, as we pass > hugepage_or_freepage = true inconditionally, which is wrong. > I think it was caused during rebasing. > > Should be: Tests passed with this patch on top of others. Thanks! -- Aristeu
Re: [PATCH v3 0/5] HWpoison: further fixes and cleanups
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 it (we did that already for soft_offline_page [1]). > > The other patches are clean-ups and not that important, so if anything, > consider patch#1 for inclusion. > > [1] https://patchwork.kernel.org/cover/11704083/ I found something strange with your and Naoya's hwpoison rework. We have a customer with a testcase that basically does: p1 = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); p2 = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); madvise(p1, size, MADV_MERGEABLE); madvise(p2, size, MADV_MERGEABLE); memset(p1, 'a', size); memset(p2, 'a', size); madvise(p1, size, MADV_SOFT_OFFLINE); madvise(p1, size, MADV_UNMERGEABLE); madvise(p2, size, MADV_UNMERGEABLE); where size is about 200,000 pages. It works on a x86_64 box (with and without the hwpoison rework). On ppc64 boxes (tested 3 different ones with at least 250GB memory) it fails to take a page off the buddy list (page_handle_poison()/take_page_off_buddy()) (madvise MADV_SOFT_OFFLINE returns -EBUSY). Without the hwpoison rework the test passes. Possibly related is that ppc64 takes a long time to run this test and according perf, it spends most of the time clearing pages: 17.15% ksm_poison [kernel.kallsyms] [k] copypage_power7 13.39% ksm_poison [kernel.kallsyms] [k] clear_user_page 8.70% ksm_poison libc-2.28.so [.] __memset_power8 8.63% ksm_poison [kernel.kallsyms] [k] opal_return 6.04% ksm_poison [kernel.kallsyms] [k] __opal_call 2.67% ksm_poison [kernel.kallsyms] [k] opal_call 1.52% ksm_poison [kernel.kallsyms] [k] _raw_spin_lock 1.45% ksm_poison [kernel.kallsyms] [k] opal_flush_console 1.43% ksm_poison [unknown] [k] 0x30005138 1.43% ksm_poison [kernel.kallsyms] [k] opal_console_write_buffer_space 1.26% ksm_poison [kernel.kallsyms] [k] hvc_console_print (...) I've run these tests using mmotm and mmotm with this patchset on top. Do you know what might be happening here? -- Aristeu
Re: [PATCH] EDAC/ie31200: fallback if host bridge device is already initialized
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 > > So Tested-by: you ? Not by me, "we" meant as in company. Tested-by: Vishal Agrawal -- Aristeu
Re: [PATCH] EDAC/ie31200: fallback if host bridge device is already initialized
On Thu, Jul 16, 2020 at 02:25:11PM -0400, Jason Baron wrote:
> The Intel uncore driver may claim some of the pci ids from ie31200 which
> means that the ie31200 edac driver will not initialize them as part of
> pci_register_driver().
>
> Let's add a fallback for this case to 'pci_get_device()' to get a
> reference on the device such that it can still be configured. This is
> similar in approach to other edac drivers.
>
> Signed-off-by: Jason Baron
> Cc: Borislav Petkov
> Cc: Mauro Carvalho Chehab
> Cc: Tony Luck
> Cc: linux-edac
> ---
> drivers/edac/ie31200_edac.c | 50
> ++---
> 1 file changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/edac/ie31200_edac.c b/drivers/edac/ie31200_edac.c
> index d68346a..ebe5099 100644
> --- a/drivers/edac/ie31200_edac.c
> +++ b/drivers/edac/ie31200_edac.c
> @@ -170,6 +170,8 @@
> (n << (28 + (2 * skl) - PAGE_SHIFT))
>
> static int nr_channels;
> +static struct pci_dev *mci_pdev;
> +static int ie31200_registered = 1;
>
> struct ie31200_priv {
> void __iomem *window;
> @@ -538,12 +540,16 @@ static int ie31200_probe1(struct pci_dev *pdev, int
> dev_idx)
> static int ie31200_init_one(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> {
> - edac_dbg(0, "MC:\n");
> + int rc;
>
> + edac_dbg(0, "MC:\n");
> if (pci_enable_device(pdev) < 0)
> return -EIO;
> + rc = ie31200_probe1(pdev, ent->driver_data);
> + if (rc == 0 && !mci_pdev)
> + mci_pdev = pci_dev_get(pdev);
>
> - return ie31200_probe1(pdev, ent->driver_data);
> + return rc;
> }
>
> static void ie31200_remove_one(struct pci_dev *pdev)
> @@ -552,6 +558,8 @@ static void ie31200_remove_one(struct pci_dev *pdev)
> struct ie31200_priv *priv;
>
> edac_dbg(0, "\n");
> + pci_dev_put(mci_pdev);
> + mci_pdev = NULL;
> mci = edac_mc_del_mc(>dev);
> if (!mci)
> return;
> @@ -593,17 +601,53 @@ static struct pci_driver ie31200_driver = {
>
> static int __init ie31200_init(void)
> {
> + int pci_rc, i;
> +
> edac_dbg(3, "MC:\n");
> /* Ensure that the OPSTATE is set correctly for POLL or NMI */
> opstate_init();
>
> - return pci_register_driver(_driver);
> + pci_rc = pci_register_driver(_driver);
> + if (pci_rc < 0)
> + goto fail0;
> +
> + if (!mci_pdev) {
> + ie31200_registered = 0;
> + for (i = 0; ie31200_pci_tbl[i].vendor != 0; i++) {
> + mci_pdev = pci_get_device(ie31200_pci_tbl[i].vendor,
> + ie31200_pci_tbl[i].device,
> + NULL);
> + if (mci_pdev)
> + break;
> + }
> + if (!mci_pdev) {
> + edac_dbg(0, "ie31200 pci_get_device fail\n");
> + pci_rc = -ENODEV;
> + goto fail1;
> + }
> + pci_rc = ie31200_init_one(mci_pdev, _pci_tbl[i]);
> + if (pci_rc < 0) {
> + edac_dbg(0, "ie31200 init fail\n");
> + pci_rc = -ENODEV;
> + goto fail1;
> + }
> + }
> + return 0;
> +
> +fail1:
> + pci_unregister_driver(_driver);
> +fail0:
> + pci_dev_put(mci_pdev);
> +
> + return pci_rc;
> }
>
> static void __exit ie31200_exit(void)
> {
> edac_dbg(3, "MC:\n");
> pci_unregister_driver(_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
Re: [PATCH] Raise maximum number of memory controllers
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
Re: [PATCH] Raise maximum number of memory controllers
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
[PATCH] sysctl: do not allow a 64bit value write in a 32bit knob
Writing to a sysctl file that uses proc_dointvec_minmax like
user/max_uts_namespaces
a larger than 32 bit value won't cause an error as expected but instead will
zero
its value:
# echo 21474836480 > max_uts_namespaces
# cat max_uts_namespaces
0
This patches 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,
unsigned long *lvalp,
if (write) {
int val = *negp ? -*lvalp : *lvalp;
if ((param->min && *param->min > val) ||
- (param->max && *param->max < val))
+ (param->max && *param->max < val) ||
+ *lvalp >> (sizeof(int) * 8))
return -EINVAL;
*valp = val;
} else {
[PATCH] sysctl: do not allow a 64bit value write in a 32bit knob
Writing to a sysctl file that uses proc_dointvec_minmax like
user/max_uts_namespaces
a larger than 32 bit value won't cause an error as expected but instead will
zero
its value:
# echo 21474836480 > max_uts_namespaces
# cat max_uts_namespaces
0
This patches 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,
unsigned long *lvalp,
if (write) {
int val = *negp ? -*lvalp : *lvalp;
if ((param->min && *param->min > val) ||
- (param->max && *param->max < val))
+ (param->max && *param->max < val) ||
+ *lvalp >> (sizeof(int) * 8))
return -EINVAL;
*valp = val;
} else {
Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac
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 deal with. > > So how do you want to deal with this? > > Maintain an evergrowing whitelist of platforms which are OK and then the > moment a new platform comes along, you send a patch to add it to that > whitelist? That would also need to keep an eye on versions. A newer version of BIOS on a whitelisted platform might be broken. -- Aristeu
Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac
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 deal with. > > So how do you want to deal with this? > > Maintain an evergrowing whitelist of platforms which are OK and then the > moment a new platform comes along, you send a patch to add it to that > whitelist? That would also need to keep an eye on versions. A newer version of BIOS on a whitelisted platform might be broken. -- Aristeu
Re: [PATCH] EDAC, sb_edac: Fixed logic error in sb_edac driver
On Mon, Mar 07, 2016 at 03:30:45PM +0100, Hubert Chrzaniuk wrote:
> Patch corrects a typo introduced previously.
> As a result under some configurations dimms were not
> correctly recognized. Problem affects only Xeon Phi architecture.
>
> Signed-off-by: Hubert Chrzaniuk <hubert.chrzan...@intel.com>
> ---
> drivers/edac/sb_edac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index e438ee5..f5c6b97 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -1574,7 +1574,7 @@ static int knl_get_dimm_capacity(struct sbridge_pvt
> *pvt, u64 *mc_sizes)
> for (cha = 0; cha < KNL_MAX_CHAS; cha++) {
> if (knl_get_mc_route(target,
> mc_route_reg[cha]) == channel
> - && participants[channel]) {
> + && !participants[channel]) {
> participant_count++;
> participants[channel] = 1;
> break;
I can confirm this fixes the issues I've seen with the upstream driver.
Acked-by: Aristeu Rozanski <a...@redhat.com>
--
Aristeu
Re: [PATCH] EDAC, sb_edac: Fixed logic error in sb_edac driver
On Mon, Mar 07, 2016 at 03:30:45PM +0100, Hubert Chrzaniuk wrote:
> Patch corrects a typo introduced previously.
> As a result under some configurations dimms were not
> correctly recognized. Problem affects only Xeon Phi architecture.
>
> Signed-off-by: Hubert Chrzaniuk
> ---
> drivers/edac/sb_edac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index e438ee5..f5c6b97 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -1574,7 +1574,7 @@ static int knl_get_dimm_capacity(struct sbridge_pvt
> *pvt, u64 *mc_sizes)
> for (cha = 0; cha < KNL_MAX_CHAS; cha++) {
> if (knl_get_mc_route(target,
> mc_route_reg[cha]) == channel
> - && participants[channel]) {
> + && !participants[channel]) {
> participant_count++;
> participants[channel] = 1;
> break;
I can confirm this fixes the issues I've seen with the upstream driver.
Acked-by: Aristeu Rozanski
--
Aristeu
Re: [PATCH] oom_kill: add option to disable dump_stack()
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 architectures but the transition doesn't have to > be all at once I guess. Ok, will keep working on it then. -- 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/
Re: [PATCH] oom_kill: add option to disable dump_stack()
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 different parts of the OOM > > > report by loglevel properly? > > > pr_err - killed task report > > > pr_warning - oom invocation + memory info > > > pr_notice - task list > > > pr_info - stack trace > > > > That'd work, yes, but I'd think the stack trace would be pr_debug. At a > > point that you suspect the OOM killer isn't doing the right thing picking > > up tasks and you need more information. > > Stack trace should be independent on the oom victim selection because > the selection should be as much deterministic as possible - so it should > only depend on the memory consumption. I do agree that the exact trace > is not very useful for the (maybe) majority of OOM reports. I am trying > to remember when it was really useful the last time and have trouble to > find an example. So I would tend to agree that pr_debug would me more > suitable. Only problem I see so far with this approach is that it'll require reworing show_stack() on all architectures in order to be able to pass and use log level and I'm wondering if it's something people will find useful for other uses. -- 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/
Re: [PATCH] oom_kill: add option to disable dump_stack()
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 different parts of the OOM > > > report by loglevel properly? > > > pr_err - killed task report > > > pr_warning - oom invocation + memory info > > > pr_notice - task list > > > pr_info - stack trace > > > > That'd work, yes, but I'd think the stack trace would be pr_debug. At a > > point that you suspect the OOM killer isn't doing the right thing picking > > up tasks and you need more information. > > Stack trace should be independent on the oom victim selection because > the selection should be as much deterministic as possible - so it should > only depend on the memory consumption. I do agree that the exact trace > is not very useful for the (maybe) majority of OOM reports. I am trying > to remember when it was really useful the last time and have trouble to > find an example. So I would tend to agree that pr_debug would me more > suitable. Only problem I see so far with this approach is that it'll require reworing show_stack() on all architectures in order to be able to pass and use log level and I'm wondering if it's something people will find useful for other uses. -- 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/
Re: [PATCH] oom_kill: add option to disable dump_stack()
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 architectures but the transition doesn't have to > be all at once I guess. Ok, will keep working on it then. -- 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/
Re: [PATCH] oom_kill: add option to disable dump_stack()
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. > > Could you include sample output of before and after in the changelog > to provide an immediate comparison on what we are saving? Sure, at the end of email. > Should we make the knob specific to the stack dump or should it be > more generic, so that we could potentially save even more output? Perhaps what Michal proposed, to use printk() levels. Sure: wc -l on the logs: 47 /tmp/today.txt 27 /tmp/without_dump_stack.txt as is: [248285.939528] memhog invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0 [248285.939531] memhog cpuset=/ mems_allowed=0 [248285.939535] CPU: 1 PID: 2130 Comm: memhog Not tainted 4.3.0-rc6+ #132 [248285.939536] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [248285.939538] 88007c037d58 812bda53 8800313990c0 811b2f3a [248285.939539] 1288 811082a9 0001 88007fffbb28 [248285.939541] 0003 0206 88007c037d58 [248285.939542] Call Trace: [248285.939548] [] ? dump_stack+0x40/0x5d [248285.939550] [] ? dump_header+0x76/0x1e1 [248285.939553] [] ? delayacct_end+0x39/0x60 [248285.939556] [] ? oom_kill_process+0x1be/0x380 [248285.939559] [] ? security_capable_noaudit+0x3e/0x60 [248285.939563] [] ? out_of_memory+0x44b/0x460 [248285.939565] [] ? __alloc_pages_nodemask+0x893/0x9e0 [248285.939567] [] ? alloc_pages_vma+0xc7/0x230 [248285.939570] [] ? mem_cgroup_try_charge+0x7c/0x1a0 [248285.939572] [] ? handle_mm_fault+0x130a/0x1680 [248285.939574] [] ? do_mmap+0x336/0x420 [248285.939575] [] ? vm_mmap_pgoff+0x9c/0xc0 [248285.939578] [] ? __do_page_fault+0x186/0x410 [248285.939581] [] ? async_page_fault+0x28/0x30 [248285.939582] Mem-Info: [248285.939585] active_anon:501670 inactive_anon:43 isolated_anon:0 active_file:16 inactive_file:21 isolated_file:0 unevictable:0 dirty:9 writeback:0 unstable:0 slab_reclaimable:1780 slab_unreclaimable:2045 mapped:6 shmem:59 pagetables:1474 bounce:0 free:3388 free_pcp:0 free_cma:0 [248285.939587] Node 0 DMA free:7988kB min:40kB low:48kB high:60kB active_anon:7540kB inactive_anon:4kB active_file:8kB inactive_file:8kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:12kB shmem:12kB slab_reclaimable:28kB slab_unreclaimable:56kB kernel_stack:64kB pagetables:56kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:100 all_unreclaimable? yes [248285.939590] lowmem_reserve[]: 0 1988 1988 1988 [248285.939592] Node 0 DMA32 free:5564kB min:5588kB low:6984kB high:8380kB active_anon:1999140kB inactive_anon:168kB active_file:56kB inactive_file:76kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2080760kB managed:2038396kB mlocked:0kB dirty:36kB writeback:0kB mapped:12kB shmem:224kB slab_reclaimable:7092kB slab_unreclaimable:8124kB kernel_stack:2448kB pagetables:5840kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:1260 all_unreclaimable? yes [248285.939595] lowmem_reserve[]: 0 0 0 0 [248285.939597] Node 0 DMA: 6*4kB (UEM) 2*8kB (UE) 5*16kB (UE) 0*32kB 5*64kB (UE) 5*128kB (UEM) 3*256kB (UE) 2*512kB (EM) 3*1024kB (UE) 1*2048kB (U) 0*4096kB = 7992kB [248285.939604] Node 0 DMA32: 197*4kB (UEM) 46*8kB (UE) 11*16kB (UE) 4*32kB (UEM) 0*64kB 3*128kB (UEM) 1*256kB (M) 3*512kB (U) 2*1024kB (UM) 0*2048kB 0*4096kB = 5684kB [248285.939610] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [248285.939611] 80 total pagecache pages [248285.939612] 0 pages in swap cache [248285.939613] Swap cache stats: add 0, delete 0, find 0/0 [248285.939613] Free swap = 0kB [248285.939614] Total swap = 0kB [248285.939614] 524188 pages RAM [248285.939615] 0 pages HighMem/MovableOnly [248285.939616] 10612 pages reserved [248285.939616] 0 pages hwpoisoned [248285.939617] Out of memory: Kill process 2130 (memhog) score 943 or sacrifice child [248285.939726] Killed process 2130 (memhog) total-vm:1998720kB, anon-rss:1994396kB, file-rss:4kB - without stack trace: - [248310.662881] memhog invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [248310.662885] memhog cpuset=/ mems_allowed=0 [248310.662888] Mem-Info: [248310.662891] active_anon:501678 inactive_anon:43 isolated_anon:0 active_file:23 inactive_file:13 isolated_file:0 unevictable:0 dirty:16 writeback:0 unstable:0
Re: [PATCH] oom_kill: add option to disable dump_stack()
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 there any other reasons? One would be that the stack trace isn't very useful for users IMHO. > I am not sure sysctl is a good way to tell this particular restriction > on the output. What if somebody else doesn't want to see the list of > eligible tasks? Should we add another knob? > > Would it make more sense to distinguish different parts of the OOM > report by loglevel properly? > pr_err - killed task report > pr_warning - oom invocation + memory info > pr_notice - task list > pr_info - stack trace That'd work, yes, but I'd think the stack trace would be pr_debug. At a point that you suspect the OOM killer isn't doing the right thing picking up tasks and you need more information. -- 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/
Re: [PATCH] oom_kill: add option to disable dump_stack()
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 there any other reasons? One would be that the stack trace isn't very useful for users IMHO. > I am not sure sysctl is a good way to tell this particular restriction > on the output. What if somebody else doesn't want to see the list of > eligible tasks? Should we add another knob? > > Would it make more sense to distinguish different parts of the OOM > report by loglevel properly? > pr_err - killed task report > pr_warning - oom invocation + memory info > pr_notice - task list > pr_info - stack trace That'd work, yes, but I'd think the stack trace would be pr_debug. At a point that you suspect the OOM killer isn't doing the right thing picking up tasks and you need more information. -- 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/
Re: [PATCH] oom_kill: add option to disable dump_stack()
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. > > Could you include sample output of before and after in the changelog > to provide an immediate comparison on what we are saving? Sure, at the end of email. > Should we make the knob specific to the stack dump or should it be > more generic, so that we could potentially save even more output? Perhaps what Michal proposed, to use printk() levels. Sure: wc -l on the logs: 47 /tmp/today.txt 27 /tmp/without_dump_stack.txt as is: [248285.939528] memhog invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0 [248285.939531] memhog cpuset=/ mems_allowed=0 [248285.939535] CPU: 1 PID: 2130 Comm: memhog Not tainted 4.3.0-rc6+ #132 [248285.939536] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [248285.939538] 88007c037d58 812bda53 8800313990c0 811b2f3a [248285.939539] 1288 811082a9 0001 88007fffbb28 [248285.939541] 0003 0206 88007c037d58 [248285.939542] Call Trace: [248285.939548] [] ? dump_stack+0x40/0x5d [248285.939550] [] ? dump_header+0x76/0x1e1 [248285.939553] [] ? delayacct_end+0x39/0x60 [248285.939556] [] ? oom_kill_process+0x1be/0x380 [248285.939559] [] ? security_capable_noaudit+0x3e/0x60 [248285.939563] [] ? out_of_memory+0x44b/0x460 [248285.939565] [] ? __alloc_pages_nodemask+0x893/0x9e0 [248285.939567] [] ? alloc_pages_vma+0xc7/0x230 [248285.939570] [] ? mem_cgroup_try_charge+0x7c/0x1a0 [248285.939572] [] ? handle_mm_fault+0x130a/0x1680 [248285.939574] [] ? do_mmap+0x336/0x420 [248285.939575] [] ? vm_mmap_pgoff+0x9c/0xc0 [248285.939578] [] ? __do_page_fault+0x186/0x410 [248285.939581] [] ? async_page_fault+0x28/0x30 [248285.939582] Mem-Info: [248285.939585] active_anon:501670 inactive_anon:43 isolated_anon:0 active_file:16 inactive_file:21 isolated_file:0 unevictable:0 dirty:9 writeback:0 unstable:0 slab_reclaimable:1780 slab_unreclaimable:2045 mapped:6 shmem:59 pagetables:1474 bounce:0 free:3388 free_pcp:0 free_cma:0 [248285.939587] Node 0 DMA free:7988kB min:40kB low:48kB high:60kB active_anon:7540kB inactive_anon:4kB active_file:8kB inactive_file:8kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:12kB shmem:12kB slab_reclaimable:28kB slab_unreclaimable:56kB kernel_stack:64kB pagetables:56kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:100 all_unreclaimable? yes [248285.939590] lowmem_reserve[]: 0 1988 1988 1988 [248285.939592] Node 0 DMA32 free:5564kB min:5588kB low:6984kB high:8380kB active_anon:1999140kB inactive_anon:168kB active_file:56kB inactive_file:76kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2080760kB managed:2038396kB mlocked:0kB dirty:36kB writeback:0kB mapped:12kB shmem:224kB slab_reclaimable:7092kB slab_unreclaimable:8124kB kernel_stack:2448kB pagetables:5840kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:1260 all_unreclaimable? yes [248285.939595] lowmem_reserve[]: 0 0 0 0 [248285.939597] Node 0 DMA: 6*4kB (UEM) 2*8kB (UE) 5*16kB (UE) 0*32kB 5*64kB (UE) 5*128kB (UEM) 3*256kB (UE) 2*512kB (EM) 3*1024kB (UE) 1*2048kB (U) 0*4096kB = 7992kB [248285.939604] Node 0 DMA32: 197*4kB (UEM) 46*8kB (UE) 11*16kB (UE) 4*32kB (UEM) 0*64kB 3*128kB (UEM) 1*256kB (M) 3*512kB (U) 2*1024kB (UM) 0*2048kB 0*4096kB = 5684kB [248285.939610] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [248285.939611] 80 total pagecache pages [248285.939612] 0 pages in swap cache [248285.939613] Swap cache stats: add 0, delete 0, find 0/0 [248285.939613] Free swap = 0kB [248285.939614] Total swap = 0kB [248285.939614] 524188 pages RAM [248285.939615] 0 pages HighMem/MovableOnly [248285.939616] 10612 pages reserved [248285.939616] 0 pages hwpoisoned [248285.939617] Out of memory: Kill process 2130 (memhog) score 943 or sacrifice child [248285.939726] Killed process 2130 (memhog) total-vm:1998720kB, anon-rss:1994396kB, file-rss:4kB - without stack trace: - [248310.662881] memhog invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [248310.662885] memhog cpuset=/ mems_allowed=0 [248310.662888] Mem-Info: [248310.662891] active_anon:501678 inactive_anon:43 isolated_anon:0 active_file:23 inactive_file:13 isolated_file:0 unevictable:0 dirty:16 writeback:0 unstable:0
[PATCH] oom_kill: add option to disable dump_stack()
One of the largest chunks of log messages in a OOM is from dump_stack() and in
some cases it isn't even necessary to figure out what's going on. In
systems with multiple tenants/containers with limited resources each
OOMs can be way more frequent and being able to reduce the amount of 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: Aristeu Rozanski
---
include/linux/oom.h | 1 +
kernel/sysctl.c | 7 +++
mm/oom_kill.c | 4 +++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/oom.h b/include/linux/oom.h
index 03e6257..bdd03e5 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -115,6 +115,7 @@ static inline bool task_will_free_mem(struct task_struct
*task)
/* sysctls */
extern int sysctl_oom_dump_tasks;
+extern int sysctl_oom_dump_stack;
extern int sysctl_oom_kill_allocating_task;
extern int sysctl_panic_on_oom;
#endif /* _INCLUDE_LINUX_OOM_H */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index e69201d..c812523 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1176,6 +1176,13 @@ static struct ctl_table vm_table[] = {
.proc_handler = proc_dointvec,
},
{
+ .procname = "oom_dump_stack",
+ .data = _oom_dump_stack,
+ .maxlen = sizeof(sysctl_oom_dump_stack),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
.procname = "overcommit_ratio",
.data = _overcommit_ratio,
.maxlen = sizeof(sysctl_overcommit_ratio),
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 1ecc0bc..bdbf83b 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -42,6 +42,7 @@
int sysctl_panic_on_oom;
int sysctl_oom_kill_allocating_task;
int sysctl_oom_dump_tasks = 1;
+int sysctl_oom_dump_stack = 1;
DEFINE_MUTEX(oom_lock);
@@ -384,7 +385,8 @@ static void dump_header(struct oom_control *oc, struct
task_struct *p,
current->signal->oom_score_adj);
cpuset_print_task_mems_allowed(current);
task_unlock(current);
- dump_stack();
+ if (sysctl_oom_dump_stack)
+ dump_stack();
if (memcg)
mem_cgroup_print_oom_info(memcg, p);
else
--
1.8.3.1
--
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/
[PATCH] oom_kill: add option to disable dump_stack()
One of the largest chunks of log messages in a OOM is from dump_stack() and in
some cases it isn't even necessary to figure out what's going on. In
systems with multiple tenants/containers with limited resources each
OOMs can be way more frequent and being able to reduce the amount of 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 <gthe...@google.com>
Cc: Johannes Weiner <han...@cmpxchg.org>
Cc: linux...@kvack.org
Cc: cgro...@vger.kernel.org
Signed-off-by: Aristeu Rozanski <aroza...@redhat.com>
---
include/linux/oom.h | 1 +
kernel/sysctl.c | 7 +++
mm/oom_kill.c | 4 +++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/oom.h b/include/linux/oom.h
index 03e6257..bdd03e5 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -115,6 +115,7 @@ static inline bool task_will_free_mem(struct task_struct
*task)
/* sysctls */
extern int sysctl_oom_dump_tasks;
+extern int sysctl_oom_dump_stack;
extern int sysctl_oom_kill_allocating_task;
extern int sysctl_panic_on_oom;
#endif /* _INCLUDE_LINUX_OOM_H */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index e69201d..c812523 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1176,6 +1176,13 @@ static struct ctl_table vm_table[] = {
.proc_handler = proc_dointvec,
},
{
+ .procname = "oom_dump_stack",
+ .data = _oom_dump_stack,
+ .maxlen = sizeof(sysctl_oom_dump_stack),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
.procname = "overcommit_ratio",
.data = _overcommit_ratio,
.maxlen = sizeof(sysctl_overcommit_ratio),
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 1ecc0bc..bdbf83b 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -42,6 +42,7 @@
int sysctl_panic_on_oom;
int sysctl_oom_kill_allocating_task;
int sysctl_oom_dump_tasks = 1;
+int sysctl_oom_dump_stack = 1;
DEFINE_MUTEX(oom_lock);
@@ -384,7 +385,8 @@ static void dump_header(struct oom_control *oc, struct
task_struct *p,
current->signal->oom_score_adj);
cpuset_print_task_mems_allowed(current);
task_unlock(current);
- dump_stack();
+ if (sysctl_oom_dump_stack)
+ dump_stack();
if (memcg)
mem_cgroup_print_oom_info(memcg, p);
else
--
1.8.3.1
--
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/
Re: [PATCH] ipc,sem: fix use after free on IPC_RMID after a task using same semaphore set exits
On Fri, Aug 07, 2015 at 02:09:35PM -0300, Herton R. Krzesinski wrote:
> The current semaphore code allows a potential use after free: in exit_sem we
> may
> free the task's sem_undo_list while there is still another task looping
> through
> the same semaphore set and cleaning the sem_undo list at freeary function (the
> task called IPC_RMID for the same semaphore set).
>
> For example, with a test program [1] running which keeps forking a lot of
> processes
> (which then do a semop call with SEM_UNDO flag), and with the parent right
> after
> removing the semaphore set with IPC_RMID, and a kernel built with CONFIG_SLAB,
> CONFIG_SLAB_DEBUG and CONFIG_DEBUG_SPINLOCK, you can easily see something like
> the following in the kernel log:
(snip)
> Signed-off-by: Herton R. Krzesinski
> ---
> ipc/sem.c | 24
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/ipc/sem.c b/ipc/sem.c
> index bc3d530..35ccddd 100644
> --- a/ipc/sem.c
> +++ b/ipc/sem.c
> @@ -2074,17 +2074,24 @@ void exit_sem(struct task_struct *tsk)
> rcu_read_lock();
> un = list_entry_rcu(ulp->list_proc.next,
> struct sem_undo, list_proc);
> - if (>list_proc == >list_proc)
> - semid = -1;
> - else
> - semid = un->semid;
> + if (>list_proc == >list_proc) {
> + rcu_read_unlock();
> + /* Make sure we wait for any place still referencing
> + * the current ulp to finish */
> + synchronize_rcu();
> + break;
> + }
> + spin_lock(>lock);
> + semid = un->semid;
> + spin_unlock(>lock);
>
> + /* exit_sem raced with IPC_RMID, nothing to do */
> if (semid == -1) {
> rcu_read_unlock();
> - break;
> + continue;
> }
>
> - sma = sem_obtain_object_check(tsk->nsproxy->ipc_ns, un->semid);
> + sma = sem_obtain_object_check(tsk->nsproxy->ipc_ns, semid);
> /* exit_sem raced with IPC_RMID, nothing to do */
> if (IS_ERR(sma)) {
> rcu_read_unlock();
> @@ -2112,9 +2119,10 @@ void exit_sem(struct task_struct *tsk)
> ipc_assert_locked_object(>sem_perm);
> list_del(>list_id);
>
> - spin_lock(>lock);
> + /* we should be the last process using this ulp, so no need
> + * to acquire ulp->lock here; we are also protected against
> + * IPC_RMID as we hold sma->sem_perm.lock */
> list_del_rcu(>list_proc);
> - spin_unlock(>lock);
>
> /* perform adjustments registered in un */
> for (i = 0; i < sma->sem_nsems; i++) {
I was debugging the same issue and can confirm this fix works and makes
sense.
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/
Re: [PATCH] ipc,sem: fix use after free on IPC_RMID after a task using same semaphore set exits
On Fri, Aug 07, 2015 at 02:09:35PM -0300, Herton R. Krzesinski wrote:
The current semaphore code allows a potential use after free: in exit_sem we
may
free the task's sem_undo_list while there is still another task looping
through
the same semaphore set and cleaning the sem_undo list at freeary function (the
task called IPC_RMID for the same semaphore set).
For example, with a test program [1] running which keeps forking a lot of
processes
(which then do a semop call with SEM_UNDO flag), and with the parent right
after
removing the semaphore set with IPC_RMID, and a kernel built with CONFIG_SLAB,
CONFIG_SLAB_DEBUG and CONFIG_DEBUG_SPINLOCK, you can easily see something like
the following in the kernel log:
(snip)
Signed-off-by: Herton R. Krzesinski her...@redhat.com
---
ipc/sem.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index bc3d530..35ccddd 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -2074,17 +2074,24 @@ void exit_sem(struct task_struct *tsk)
rcu_read_lock();
un = list_entry_rcu(ulp-list_proc.next,
struct sem_undo, list_proc);
- if (un-list_proc == ulp-list_proc)
- semid = -1;
- else
- semid = un-semid;
+ if (un-list_proc == ulp-list_proc) {
+ rcu_read_unlock();
+ /* Make sure we wait for any place still referencing
+ * the current ulp to finish */
+ synchronize_rcu();
+ break;
+ }
+ spin_lock(ulp-lock);
+ semid = un-semid;
+ spin_unlock(ulp-lock);
+ /* exit_sem raced with IPC_RMID, nothing to do */
if (semid == -1) {
rcu_read_unlock();
- break;
+ continue;
}
- sma = sem_obtain_object_check(tsk-nsproxy-ipc_ns, un-semid);
+ sma = sem_obtain_object_check(tsk-nsproxy-ipc_ns, semid);
/* exit_sem raced with IPC_RMID, nothing to do */
if (IS_ERR(sma)) {
rcu_read_unlock();
@@ -2112,9 +2119,10 @@ void exit_sem(struct task_struct *tsk)
ipc_assert_locked_object(sma-sem_perm);
list_del(un-list_id);
- spin_lock(ulp-lock);
+ /* we should be the last process using this ulp, so no need
+ * to acquire ulp-lock here; we are also protected against
+ * 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++) {
I was debugging the same issue and can confirm this fix works and makes
sense.
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
Re: [PATCH] sb_edac: fix TAD presence check for sbridge_mci_bind_devs()
On Wed, Aug 05, 2015 at 01:16:01PM -0500, Seth Jennings wrote:
> In 7d375bff, NUM_CHANNELS was changed to 8 and the channel space was
> renumerated to handle EN, EP, and EX configurations.
>
> The *_mci_bind_devs functions, except for sbridge_mci_bind_devs(), got a
> new device presence check in the form of saw_chan_mask. However,
> sbridge_mci_bind_devs() still uses the NUM_CHANNELS for loop.
>
> With the increase in NUM_CHANNELS, this loop fails at index 4 since
> SB only has 4 TADs. This results in the following error on SB machines:
>
> EDAC sbridge: Some needed devices are missing
> EDAC sbridge: Couldn't find mci handler
> EDAC sbridge: Couldn't find mci handle
>
> This patch adapts the saw_chan_mask logic for sbridge_mci_bind_devs() as
> well.
>
> After this patch:
>
> EDAC MC0: Giving out device to 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
> ---
> drivers/edac/sb_edac.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index ca78311..91cf710 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -1648,6 +1648,7 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info
> *mci,
> {
> struct sbridge_pvt *pvt = mci->pvt_info;
> struct pci_dev *pdev;
> + u8 saw_chan_mask = 0;
> int i;
>
> for (i = 0; i < sbridge_dev->n_devs; i++) {
> @@ -1681,6 +1682,7 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info
> *mci,
> {
> int id = pdev->device -
> PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0;
> pvt->pci_tad[id] = pdev;
> + saw_chan_mask |= 1 << id;
> }
> break;
> case PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO:
> @@ -1701,10 +1703,8 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info
> *mci,
> !pvt-> pci_tad || !pvt->pci_ras || !pvt->pci_ta)
> goto enodev;
>
> - for (i = 0; i < NUM_CHANNELS; i++) {
> - if (!pvt->pci_tad[i])
> - goto enodev;
> - }
> + if (saw_chan_mask != 0x0f)
> + goto enodev;
> return 0;
>
> enodev:
> --
> 2.4.3
>
--
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/
Re: [PATCH] sb_edac: fix TAD presence check for sbridge_mci_bind_devs()
On Wed, Aug 05, 2015 at 01:16:01PM -0500, Seth Jennings wrote:
In 7d375bff, NUM_CHANNELS was changed to 8 and the channel space was
renumerated to handle EN, EP, and EX configurations.
The *_mci_bind_devs functions, except for sbridge_mci_bind_devs(), got a
new device presence check in the form of saw_chan_mask. However,
sbridge_mci_bind_devs() still uses the NUM_CHANNELS for loop.
With the increase in NUM_CHANNELS, this loop fails at index 4 since
SB only has 4 TADs. This results in the following error on SB machines:
EDAC sbridge: Some needed devices are missing
EDAC sbridge: Couldn't find mci handler
EDAC sbridge: Couldn't find mci handle
This patch adapts the saw_chan_mask logic for sbridge_mci_bind_devs() as
well.
After this patch:
EDAC MC0: Giving out device to 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 a...@redhat.com
Signed-off-by: Seth Jennings sjenn...@redhat.com
---
drivers/edac/sb_edac.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index ca78311..91cf710 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1648,6 +1648,7 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info
*mci,
{
struct sbridge_pvt *pvt = mci-pvt_info;
struct pci_dev *pdev;
+ u8 saw_chan_mask = 0;
int i;
for (i = 0; i sbridge_dev-n_devs; i++) {
@@ -1681,6 +1682,7 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info
*mci,
{
int id = pdev-device -
PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0;
pvt-pci_tad[id] = pdev;
+ saw_chan_mask |= 1 id;
}
break;
case PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO:
@@ -1701,10 +1703,8 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info
*mci,
!pvt- pci_tad || !pvt-pci_ras || !pvt-pci_ta)
goto enodev;
- for (i = 0; i NUM_CHANNELS; i++) {
- if (!pvt-pci_tad[i])
- goto enodev;
- }
+ if (saw_chan_mask != 0x0f)
+ goto enodev;
return 0;
enodev:
--
2.4.3
--
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/
Re: [PATCH 2/3] sb_edac: virtualize several hard-coded functions
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)(u32 reg);
> + u64 (*sad_limit)(u32 reg);
> + u32 (*interleave_mode)(u32 reg);
> + char* (*show_interleave_mode)(u32 reg);
> + u32 (*dram_attr)(u32 reg);
> const u32 *dram_rule;
> const u32 *interleave_list;
> const struct interleave_pkg *interleave_pkg;
the only reason these exist is for when there's a difference between
memory controllers:
> pvt->info.get_memory_type = get_memory_type;
> pvt->info.get_memory_type = get_memory_type;
> pvt->info.get_memory_type = haswell_get_memory_type;
until then such change isn't really necessary.
--
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/
Re: [PATCH 2/3] sb_edac: virtualize several hard-coded functions
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)(u32 reg);
+ u64 (*sad_limit)(u32 reg);
+ u32 (*interleave_mode)(u32 reg);
+ char* (*show_interleave_mode)(u32 reg);
+ u32 (*dram_attr)(u32 reg);
const u32 *dram_rule;
const u32 *interleave_list;
const struct interleave_pkg *interleave_pkg;
the only reason these exist is for when there's a difference between
memory controllers:
pvt-info.get_memory_type = get_memory_type;
pvt-info.get_memory_type = get_memory_type;
pvt-info.get_memory_type = haswell_get_memory_type;
until then such change isn't really necessary.
--
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/
Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
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 children to have > one > identifier that is inserted into all the events that are associated with the > container. > > With this, its possible to do a search for all events related to a container. > Its possible to exclude events from a container. Its possible to not get any > events. > > The requirements also call out for the identification of the subject. This > means that the event should be bound to a syscall such as clone, setns, or > unshare. > > Also, any user space events originating inside the container needs to have > the > container ID added to the user space event - just like auid and session id. > > Recording each instance of a name space is giving me something that I cannot > use to do queries required by the security target. Given these events, how do > I locate a web server event where it accesses a watched file? That > authentication failed? That an update within the container failed? > > The requirements are that we have to log the creation, suspension, migration, > and termination of a container. The requirements are not on the individual > name space. > > Maybe I'm missing how these events give me that. But I'd like to hear how I > would be able to meet requirements with these 12 events. what about cases you don't use lxc, libvirt to create namespaces? It's easier if the logging is done by namespaces and in case they're created by any container manager, it can generate a new event notifying it created a container named "foo" with these namespaces: x, y, z, w and from that you can piece together everything that happened. Userspace tools can change to adapt to using namespaces and the idea of container to make it easier to lookup for events instead of relying on a number that might not be there (think someone using unshare, ip netns, ...). It was discussed in the past and having the concept of "container" in kernel space and it's not going to happen, so userspace should deal with it. -- 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/
Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
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 children to have one identifier that is inserted into all the events that are associated with the container. With this, its possible to do a search for all events related to a container. Its possible to exclude events from a container. Its possible to not get any events. The requirements also call out for the identification of the subject. This means that the event should be bound to a syscall such as clone, setns, or unshare. Also, any user space events originating inside the container needs to have the container ID added to the user space event - just like auid and session id. Recording each instance of a name space is giving me something that I cannot use to do queries required by the security target. Given these events, how do I locate a web server event where it accesses a watched file? That authentication failed? That an update within the container failed? The requirements are that we have to log the creation, suspension, migration, and termination of a container. The requirements are not on the individual name space. Maybe I'm missing how these events give me that. But I'd like to hear how I would be able to meet requirements with these 12 events. what about cases you don't use lxc, libvirt to create namespaces? It's easier if the logging is done by namespaces and in case they're created by any container manager, it can generate a new event notifying it created a container named foo with these namespaces: x, y, z, w and from that you can piece together everything that happened. Userspace tools can change to adapt to using namespaces and the idea of container to make it easier to lookup for events instead of relying on a number that might not be there (think someone using unshare, ip netns, ...). It was discussed in the past and having the concept of container in kernel space and it's not going to happen, so userspace should deal with it. -- 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/
Re: [PATCH] n_tty_read: check for hanging tty while waiting for input
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 the controlling tty, the calling process must be a session leader; > ie., have called setsid() before ioctl(TIOCSCTTY). Check the return value > for that too. > > FWIW, the idiom for starting a session leader is for the parent to > fork a child and exit and for the child to become the session leader with > setsid() and establish its controlling tty either with ioctl(TIOCSCTTY) > or simply opening the first tty. > > The reason for this idiom is that setsid() will fail for an existing > group leader (because otherwise a group leader could abandon existing > members of its process group, leaving them without a group leader in > a different session). > > I highly recommend Ch 34 of Michael Kerrisk's book, "The Linux Programming > Interface", especially if this is not a toy project. Actually wrote this trying to reproduce a problem a customer is seeing in a commercial application, but clearly I need to read it. Specifically about the console behavior, would you recommend the same book? Every time I need details like this I fail to find any reference online. Thanks for your help -- 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/
Re: [PATCH] n_tty_read: check for hanging tty while waiting for input
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/console will not, and /dev/ttyS0 will _not_
> be closed or released because of the still-open descriptor on /dev/console.
I see.
> Ok, so the process sleeping on /dev/console read() should have received
> SIGHUP, which would wake the process and cause it to exit the
> n_tty_read() loop, thus dropping the ldisc reference it holds.
> Did it ignore the signal or perhaps the signal is masked?
Not masked on the test case (attached). Sent sighup manually and it did
receive it.
--
Aristeu
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static char *default_console = "/dev/console";
static char *default_tty = "/dev/ttyS0";
struct data {
char *console;
char *tty;
};
static void *reader(void *d)
{
struct data *data = (struct data *)d;
struct termios old_termio;
char buff[512];
int fd = -1, rc;
while (1) {
if (fd == -1) {
fd = open(data->console, O_RDWR);
if (fd < 0)
exit(1);
if (tcgetattr(fd, _termio) == -1)
exit(1);
old_termio.c_lflag = ICANON;
if (tcsetattr(fd, 0, _termio) == -1)
exit(1);
}
rc = read(fd, buff, sizeof(buff));
if (rc < 0 && errno == EAGAIN)
continue;
close(fd);
fd = -1;
}
}
void launch(void *(*fn)(void *), struct data *data)
{
if (fork() == 0)
fn(data);
}
int main(int argc, char *argv[])
{
struct data data;
int fd;
fd = open("/dev/ttyS0", O_RDWR);
close(0);
close(1);
close(2);
ioctl(fd, TIOCSCTTY, 1);
data.console = default_console;
data.tty = default_tty;
launch(reader, );
waitpid(-1, NULL, 0);
return 0;
}
--
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/
Re: [PATCH] n_tty_read: check for hanging tty while waiting for input
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 the controlling tty, the calling process must be a session leader; ie., have called setsid() before ioctl(TIOCSCTTY). Check the return value for that too. FWIW, the idiom for starting a session leader is for the parent to fork a child and exit and for the child to become the session leader with setsid() and establish its controlling tty either with ioctl(TIOCSCTTY) or simply opening the first tty. The reason for this idiom is that setsid() will fail for an existing group leader (because otherwise a group leader could abandon existing members of its process group, leaving them without a group leader in a different session). I highly recommend Ch 34 of Michael Kerrisk's book, The Linux Programming Interface, especially if this is not a toy project. Actually wrote this trying to reproduce a problem a customer is seeing in a commercial application, but clearly I need to read it. Specifically about the console behavior, would you recommend the same book? Every time I need details like this I fail to find any reference online. Thanks for your help -- 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/
Re: [PATCH] n_tty_read: check for hanging tty while waiting for input
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/console will not, and /dev/ttyS0 will _not_
be closed or released because of the still-open descriptor on /dev/console.
I see.
Ok, so the process sleeping on /dev/console read() should have received
SIGHUP, which would wake the process and cause it to exit the
n_tty_read() loop, thus dropping the ldisc reference it holds.
Did it ignore the signal or perhaps the signal is masked?
Not masked on the test case (attached). Sent sighup manually and it did
receive it.
--
Aristeu
#include stdio.h
#include stdlib.h
#include unistd.h
#include termios.h
#include errno.h
#include signal.h
#include sys/types.h
#include sys/stat.h
#include sys/wait.h
#include fcntl.h
#include sys/ioctl.h
static char *default_console = /dev/console;
static char *default_tty = /dev/ttyS0;
struct data {
char *console;
char *tty;
};
static void *reader(void *d)
{
struct data *data = (struct data *)d;
struct termios old_termio;
char buff[512];
int fd = -1, rc;
while (1) {
if (fd == -1) {
fd = open(data-console, O_RDWR);
if (fd 0)
exit(1);
if (tcgetattr(fd, old_termio) == -1)
exit(1);
old_termio.c_lflag = ICANON;
if (tcsetattr(fd, 0, old_termio) == -1)
exit(1);
}
rc = read(fd, buff, sizeof(buff));
if (rc 0 errno == EAGAIN)
continue;
close(fd);
fd = -1;
}
}
void launch(void *(*fn)(void *), struct data *data)
{
if (fork() == 0)
fn(data);
}
int main(int argc, char *argv[])
{
struct data data;
int fd;
fd = open(/dev/ttyS0, O_RDWR);
close(0);
close(1);
close(2);
ioctl(fd, TIOCSCTTY, 1);
data.console = default_console;
data.tty = default_tty;
launch(reader, data);
waitpid(-1, NULL, 0);
return 0;
}
--
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/
Re: [PATCH] n_tty_read: check for hanging tty while waiting for input
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 > > the hangup process can finish: > > This behavior is by-design; /dev/console cannot be hung-up. hangup is issued on the tty that happens to be the console. In this case, ttyS0. > What process is sleeping on /dev/console read() and what is its controlling > tty? I ask because console teardown usually happens when SIGHUP is > received by the process group. ttyS0 is the controller tty. -- 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/
[PATCH] n_tty_read: check for hanging tty while waiting for input
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
the hangup process can finish:
n_tty_read():
(..)
add_wait_queue(>read_wait, );
while (nr) {
(..)
if (!input_available_p(tty, 0)) {
if (test_bit(TTY_OTHER_CLOSED, >flags)) {
up_read(>termios_rwsem);
tty_flush_to_ldisc(tty);
down_read(>termios_rwsem);
if (!input_available_p(tty, 0)) {
retval = -EIO;
break;
}
} else {
->if (tty_hung_up_p(file))
break;
this won't work because file->f_op never gets set to _up_tty_fops:
__tty_hangup():
spin_lock(_files_lock);
/* This breaks for file handles being sent over AF_UNIX sockets ? */
list_for_each_entry(priv, >tty_files, list) {
filp = priv->file;
if (filp->f_op->write == redirected_tty_write)
cons_filp = filp;
-> if (filp->f_op->write != tty_write)
-> continue;
closecount++;
__tty_fasync(-1, filp, 0); /* can't block */
-> filp->f_op = _up_tty_fops;
}
spin_unlock(_files_lock);
refs = tty_signal_session_leader(tty, exit_session);
/* Account for the p->signal references we killed */
while (refs--)
tty_kref_put(tty);
/*
* it drops BTM and thus races with reopen
* we protect the race by TTY_HUPPING
*/
-> tty_ldisc_hangup(tty);
So while the canonical read waits for input, it'll sleep, be awaken by
tty_ldisc_hangup() and then immediately going back to sleep without
dropping the reference to the ldisc gained on tty_read(). This isn't
noticiable in a non canonical read due that it'll eventually timeout.
The proposed patch checks for TTY_HUPPING flag in order to leave if
there's no input.
This is easily reproduced by opening /dev/console (my test case was a
virtual machine with serial console), setting as canonical and waiting
on a read(). Then, in another session, killing agetty that is running on
ttyS0 which will issue a hangup.
[ 240.439045] INFO: task (agetty):1323 blocked for more than 120
seconds.
[ 240.439569] Not tainted 3.13.0-rc3+ #11
[ 240.439972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 240.440596] (agetty)D 88007fd94440 0 1323 1
0x0080
[ 240.441253] 88007bca1c50 0086 88007989b0c0
00014440
[ 240.441857] 88007bca1fd8 00014440 88007989b0c0
88007989b0c0
[ 240.442561] 88007ad46c30 7fff 0001
88007ad46c28
[ 240.443296] Call Trace:
[ 240.443506] [] schedule+0x29/0x70
[ 240.443883] [] schedule_timeout+0x209/0x2d0
[ 240.444395] [] ? check_preempt_curr+0x85/0xa0
[ 240.444850] [] ? ttwu_do_wakeup+0x19/0xd0
[ 240.445343] [] ?
ttwu_do_activate.constprop.80+0x5d/0x70
[ 240.445868] [] ? try_to_wake_up+0xeb/0x2b0
[ 240.446363] [] ldsem_down_write+0xda/0x227
[ 240.446797] [] ? default_wake_function+0x12/0x20
[ 240.447359] []
tty_ldisc_lock_pair_timeout+0x7d/0x100
[ 240.447861] [] tty_ldisc_hangup+0xc9/0x220
[ 240.448355] [] __tty_hangup+0x363/0x4b0
[ 240.448768] [] tty_ioctl+0x865/0xbb0
[ 240.449219] [] ? do_filp_open+0x3a/0x90
[ 240.449634] [] do_vfs_ioctl+0x2e0/0x4c0
[ 240.450066] [] ? file_has_perm+0x86/0xa0
[ 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
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2189,6 +2189,8 @@ static ssize_t n_tty_read(struct tty_struct *tty, struct
file *file,
} else {
if (tty_hung_up_p(file))
break;
+ if (test_bit(TTY_HUPPING, >flags))
+ break;
if (!timeout)
break;
if (file->f_flags & O_NONBLOCK) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
[PATCH] n_tty_read: check for hanging tty while waiting for input
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
the hangup process can finish:
n_tty_read():
(..)
add_wait_queue(tty-read_wait, wait);
while (nr) {
(..)
if (!input_available_p(tty, 0)) {
if (test_bit(TTY_OTHER_CLOSED, tty-flags)) {
up_read(tty-termios_rwsem);
tty_flush_to_ldisc(tty);
down_read(tty-termios_rwsem);
if (!input_available_p(tty, 0)) {
retval = -EIO;
break;
}
} else {
-if (tty_hung_up_p(file))
break;
this won't work because file-f_op never gets set to hung_up_tty_fops:
__tty_hangup():
spin_lock(tty_files_lock);
/* This breaks for file handles being sent over AF_UNIX sockets ? */
list_for_each_entry(priv, tty-tty_files, list) {
filp = priv-file;
if (filp-f_op-write == redirected_tty_write)
cons_filp = filp;
- if (filp-f_op-write != tty_write)
- continue;
closecount++;
__tty_fasync(-1, filp, 0); /* can't block */
- filp-f_op = hung_up_tty_fops;
}
spin_unlock(tty_files_lock);
refs = tty_signal_session_leader(tty, exit_session);
/* Account for the p-signal references we killed */
while (refs--)
tty_kref_put(tty);
/*
* it drops BTM and thus races with reopen
* we protect the race by TTY_HUPPING
*/
- tty_ldisc_hangup(tty);
So while the canonical read waits for input, it'll sleep, be awaken by
tty_ldisc_hangup() and then immediately going back to sleep without
dropping the reference to the ldisc gained on tty_read(). This isn't
noticiable in a non canonical read due that it'll eventually timeout.
The proposed patch checks for TTY_HUPPING flag in order to leave if
there's no input.
This is easily reproduced by opening /dev/console (my test case was a
virtual machine with serial console), setting as canonical and waiting
on a read(). Then, in another session, killing agetty that is running on
ttyS0 which will issue a hangup.
[ 240.439045] INFO: task (agetty):1323 blocked for more than 120
seconds.
[ 240.439569] Not tainted 3.13.0-rc3+ #11
[ 240.439972] echo 0 /proc/sys/kernel/hung_task_timeout_secs
disables this message.
[ 240.440596] (agetty)D 88007fd94440 0 1323 1
0x0080
[ 240.441253] 88007bca1c50 0086 88007989b0c0
00014440
[ 240.441857] 88007bca1fd8 00014440 88007989b0c0
88007989b0c0
[ 240.442561] 88007ad46c30 7fff 0001
88007ad46c28
[ 240.443296] Call Trace:
[ 240.443506] [815c8c99] schedule+0x29/0x70
[ 240.443883] [815c7f59] schedule_timeout+0x209/0x2d0
[ 240.444395] [810974b5] ? check_preempt_curr+0x85/0xa0
[ 240.444850] [810974e9] ? ttwu_do_wakeup+0x19/0xd0
[ 240.445343] [8109764d] ?
ttwu_do_activate.constprop.80+0x5d/0x70
[ 240.445868] [810995eb] ? try_to_wake_up+0xeb/0x2b0
[ 240.446363] [815cbdaa] ldsem_down_write+0xda/0x227
[ 240.446797] [81099822] ? default_wake_function+0x12/0x20
[ 240.447359] [815cc43d]
tty_ldisc_lock_pair_timeout+0x7d/0x100
[ 240.447861] [8136e519] tty_ldisc_hangup+0xc9/0x220
[ 240.448355] [81365463] __tty_hangup+0x363/0x4b0
[ 240.448768] [81367cc5] tty_ioctl+0x865/0xbb0
[ 240.449219] [811bb52a] ? do_filp_open+0x3a/0x90
[ 240.449634] [811bd900] do_vfs_ioctl+0x2e0/0x4c0
[ 240.450066] [8124ea76] ? file_has_perm+0x86/0xa0
[ 240.450543] [811bdb61] SyS_ioctl+0x81/0xa0
[ 240.450921] [815d4b69] system_call_fastpath+0x16/0x1b
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.cz
Cc: Peter Hurley pe...@hurleysoftware.com
Signed-off-by: Aristeu Rozanski a...@redhat.com
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 0f74945..4fb909d 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2189,6 +2189,8 @@ static ssize_t n_tty_read(struct tty_struct *tty, struct
file *file,
} else {
if (tty_hung_up_p(file))
break;
+ if (test_bit(TTY_HUPPING, tty-flags
Re: [PATCH] n_tty_read: check for hanging tty while waiting for input
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 the hangup process can finish: This behavior is by-design; /dev/console cannot be hung-up. hangup is issued on the tty that happens to be the console. In this case, ttyS0. What process is sleeping on /dev/console read() and what is its controlling tty? I ask because console teardown usually happens when SIGHUP is received by the process group. ttyS0 is the controller tty. -- 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/
Re: [PATCH] sb_edac: Fix detection on SNB machines
On Mon, Feb 09, 2015 at 01:17:17PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
> Subject: [PATCH] sb_edac: Fix detection on SNB machines
>
> d0585cd815fa ("sb_edac: Claim a different PCI device") changed the
> probing of sb_edac to look for PCI device 0x3ca0:
>
> 3f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home
> Agent (rev 07)
> 00: 86 80 a0 3c 00 00 00 00 07 00 80 08 00 00 80 00
> ...
>
> but we're matching for 0x3ca8, i.e. PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA
> in sbridge_probe() therefore the probing fails.
>
> Changing it to probe for 0x3ca0 (PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0),
> .i.e., the 14.0 device, fixes the issue and driver loads successfully
> again:
>
> [ 2449.013120] EDAC DEBUG: sbridge_init:
> [ 2449.017029] EDAC sbridge: Seeking for: PCI ID 8086:3ca0
> [ 2449.022368] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca0
> [ 2449.028498] EDAC sbridge: Seeking for: PCI ID 8086:3ca0
> [ 2449.033768] EDAC sbridge: Seeking for: PCI ID 8086:3ca8
> [ 2449.039028] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca8
> [ 2449.045155] EDAC sbridge: Seeking for: PCI ID 8086:3ca8
> ...
>
> Add a debug printk while at it to be able to catch the failure in the
> future and dump driver version on successful load.
>
> Fixes: d0585cd815fa ("sb_edac: Claim a different PCI device")
> Cc: sta...@vger.kernel.org # 3.18
> Cc: Tony Luck
> Cc: Andy Lutomirski
> Cc: Mauro Carvalho Chehab
> Signed-off-by: Borislav Petkov
> ---
> drivers/edac/sb_edac.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index 63aa6730e89e..1acf57ba4c86 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -2447,7 +2447,7 @@ static int sbridge_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> rc = sbridge_get_all_devices(_mc,
> pci_dev_descr_ibridge_table);
> type = IVY_BRIDGE;
> break;
> - case PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA:
> + case PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0:
> rc = sbridge_get_all_devices(_mc,
> pci_dev_descr_sbridge_table);
> type = SANDY_BRIDGE;
> break;
> @@ -2460,8 +2460,11 @@ static int sbridge_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> type = BROADWELL;
> break;
> }
> - if (unlikely(rc < 0))
> + if (unlikely(rc < 0)) {
> + edac_dbg(0, "couldn't get all devices for 0x%x\n",
> pdev->device);
> goto fail0;
> + }
> +
> mc = 0;
>
> list_for_each_entry(sbridge_dev, _edac_list, list) {
> @@ -2474,7 +2477,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);
>
> mutex_unlock(_edac_lock);
> return 0;
looks good to me
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/
Re: [PATCH] sb_edac: Fix detection on SNB machines
On Mon, Feb 09, 2015 at 01:17:17PM +0100, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
Subject: [PATCH] sb_edac: Fix detection on SNB machines
d0585cd815fa (sb_edac: Claim a different PCI device) changed the
probing of sb_edac to look for PCI device 0x3ca0:
3f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home
Agent (rev 07)
00: 86 80 a0 3c 00 00 00 00 07 00 80 08 00 00 80 00
...
but we're matching for 0x3ca8, i.e. PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA
in sbridge_probe() therefore the probing fails.
Changing it to probe for 0x3ca0 (PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0),
.i.e., the 14.0 device, fixes the issue and driver loads successfully
again:
[ 2449.013120] EDAC DEBUG: sbridge_init:
[ 2449.017029] EDAC sbridge: Seeking for: PCI ID 8086:3ca0
[ 2449.022368] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca0
[ 2449.028498] EDAC sbridge: Seeking for: PCI ID 8086:3ca0
[ 2449.033768] EDAC sbridge: Seeking for: PCI ID 8086:3ca8
[ 2449.039028] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca8
[ 2449.045155] EDAC sbridge: Seeking for: PCI ID 8086:3ca8
...
Add a debug printk while at it to be able to catch the failure in the
future and dump driver version on successful load.
Fixes: d0585cd815fa (sb_edac: Claim a different PCI device)
Cc: sta...@vger.kernel.org # 3.18
Cc: Tony Luck tony.l...@intel.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/edac/sb_edac.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 63aa6730e89e..1acf57ba4c86 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -2447,7 +2447,7 @@ static int sbridge_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
rc = sbridge_get_all_devices(num_mc,
pci_dev_descr_ibridge_table);
type = IVY_BRIDGE;
break;
- case PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA:
+ case PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0:
rc = sbridge_get_all_devices(num_mc,
pci_dev_descr_sbridge_table);
type = SANDY_BRIDGE;
break;
@@ -2460,8 +2460,11 @@ static int sbridge_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
type = BROADWELL;
break;
}
- if (unlikely(rc 0))
+ if (unlikely(rc 0)) {
+ edac_dbg(0, couldn't get all devices for 0x%x\n,
pdev-device);
goto fail0;
+ }
+
mc = 0;
list_for_each_entry(sbridge_dev, sbridge_edac_list, list) {
@@ -2474,7 +2477,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);
mutex_unlock(sbridge_edac_lock);
return 0;
looks good to me
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
[PATCH] scripts/bloat-o-meter: include .rodata section comparison
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 +26,66 @@ def getsizes(file):
# statics and some other optimizations adds random .NUMBER
name = re.sub(r'\.[0-9]+', '', name)
sym[name] = sym.get(name, 0) + int(size, 16)
-return sym
-old = getsizes(sys.argv[1])
-new = getsizes(sys.argv[2])
-grow, shrink, add, remove, up, down = 0, 0, 0, 0, 0, 0
-delta, common = [], {}
+sections = {}
+exp = re.compile('[\ ]*[0-9]+[\ ]+([^\ ]+)[\ ]+([0-9a-f]+).*')
+wanted_sections = ['.rodata']
+for l in os.popen("objdump -h -w " + file).readlines():
+match = exp.match(l)
+if not match:
+continue
+name = match.group(1)
+if name not in wanted_sections:
+continue
+size = int(match.group(2), 16)
+sections[name] = size
-for a in old:
-if a in new:
-common[a] = 1
+return (sym, sections)
-for name in old:
-if name not in common:
-remove += 1
-down += old[name]
-delta.append((-old[name], name))
+def process_results(old, new):
+grow, shrink, add, remove, up, down = 0, 0, 0, 0, 0, 0
+delta, common = [], {}
+for a in old:
+if a in new:
+common[a] = 1
-for name in new:
-if name not in common:
-add += 1
-up += new[name]
-delta.append((new[name], name))
+for name in old:
+if name not in common:
+remove += 1
+down += old[name]
+delta.append((-old[name], name))
-for name in common:
-d = new.get(name, 0) - old.get(name, 0)
-if d>0: grow, up = grow+1, up+d
-if d<0: shrink, down = shrink+1, down-d
-delta.append((d, name))
+for name in new:
+if name not in common:
+add += 1
+up += new[name]
+delta.append((new[name], name))
-delta.sort()
-delta.reverse()
+for name in common:
+d = new.get(name, 0) - old.get(name, 0)
+if d>0: grow, up = grow+1, up+d
+if d<0: shrink, down = shrink+1, down-d
+delta.append((d, name))
-print "add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s (%s)" % \
- (add, remove, grow, shrink, up, -down, up-down)
-print "%-40s %7s %7s %+7s" % ("function", "old", "new", "delta")
-for d, n in delta:
-if d: print "%-40s %7s %7s %+7d" % (n, old.get(n,"-"), new.get(n,"-"), d)
+delta.sort()
+delta.reverse()
+
+return (add, remove, up, down, grow, shrink, delta)
+
+def print_results(title, add, remove, up, down, grow, shrink, delta, old, new):
+print "add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s (%s)" % \
+ (add, remove, grow, shrink, up, -down, up-down)
+print "%-40s %7s %7s %+7s" % (title, "old", "new", "delta")
+for d, n in delta:
+if d: print "%-40s %7s %7s %+7d" % (n, old.get(n,"-"), new.get(n,"-"),
d)
+
+old, old_sections = getsizes(sys.argv[1])
+new, new_sections = getsizes(sys.argv[2])
+
+(add, remove, up, down, grow, shrink, delta) = process_results(old, new)
+print "Symbols changes"
+print_results("function", add, remove, up, down, grow, shrink, delta, old, new)
+
+(add, remove, up, down, grow, shrink, delta) = process_results(old_sections,
new_sections)
+print "\nSection changes"
+print_results("section", add, remove, up, down, grow, shrink, delta,
old_sections, new_sections)
--
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/
[PATCH] scripts/bloat-o-meter: include .rodata section comparison
This patch adds section .rodata comparison in order to detect string
constant changes.
Cc: Josh Triplett j...@joshtriplett.org
Signed-off-by: Aristeu Rozanski a...@redhat.com
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 +26,66 @@ def getsizes(file):
# statics and some other optimizations adds random .NUMBER
name = re.sub(r'\.[0-9]+', '', name)
sym[name] = sym.get(name, 0) + int(size, 16)
-return sym
-old = getsizes(sys.argv[1])
-new = getsizes(sys.argv[2])
-grow, shrink, add, remove, up, down = 0, 0, 0, 0, 0, 0
-delta, common = [], {}
+sections = {}
+exp = re.compile('[\ ]*[0-9]+[\ ]+([^\ ]+)[\ ]+([0-9a-f]+).*')
+wanted_sections = ['.rodata']
+for l in os.popen(objdump -h -w + file).readlines():
+match = exp.match(l)
+if not match:
+continue
+name = match.group(1)
+if name not in wanted_sections:
+continue
+size = int(match.group(2), 16)
+sections[name] = size
-for a in old:
-if a in new:
-common[a] = 1
+return (sym, sections)
-for name in old:
-if name not in common:
-remove += 1
-down += old[name]
-delta.append((-old[name], name))
+def process_results(old, new):
+grow, shrink, add, remove, up, down = 0, 0, 0, 0, 0, 0
+delta, common = [], {}
+for a in old:
+if a in new:
+common[a] = 1
-for name in new:
-if name not in common:
-add += 1
-up += new[name]
-delta.append((new[name], name))
+for name in old:
+if name not in common:
+remove += 1
+down += old[name]
+delta.append((-old[name], name))
-for name in common:
-d = new.get(name, 0) - old.get(name, 0)
-if d0: grow, up = grow+1, up+d
-if d0: shrink, down = shrink+1, down-d
-delta.append((d, name))
+for name in new:
+if name not in common:
+add += 1
+up += new[name]
+delta.append((new[name], name))
-delta.sort()
-delta.reverse()
+for name in common:
+d = new.get(name, 0) - old.get(name, 0)
+if d0: grow, up = grow+1, up+d
+if d0: shrink, down = shrink+1, down-d
+delta.append((d, name))
-print add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s (%s) % \
- (add, remove, grow, shrink, up, -down, up-down)
-print %-40s %7s %7s %+7s % (function, old, new, delta)
-for d, n in delta:
-if d: print %-40s %7s %7s %+7d % (n, old.get(n,-), new.get(n,-), d)
+delta.sort()
+delta.reverse()
+
+return (add, remove, up, down, grow, shrink, delta)
+
+def print_results(title, add, remove, up, down, grow, shrink, delta, old, new):
+print add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s (%s) % \
+ (add, remove, grow, shrink, up, -down, up-down)
+print %-40s %7s %7s %+7s % (title, old, new, delta)
+for d, n in delta:
+if d: print %-40s %7s %7s %+7d % (n, old.get(n,-), new.get(n,-),
d)
+
+old, old_sections = getsizes(sys.argv[1])
+new, new_sections = getsizes(sys.argv[2])
+
+(add, remove, up, down, grow, shrink, delta) = process_results(old, new)
+print Symbols changes
+print_results(function, add, remove, up, down, grow, shrink, delta, old, new)
+
+(add, remove, up, down, grow, shrink, delta) = process_results(old_sections,
new_sections)
+print \nSection changes
+print_results(section, add, remove, up, down, grow, shrink, delta,
old_sections, new_sections)
--
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/
Re: [LKP] [sb_edac] 50d1bb93672: EDAC sbridge: ECC is disabled. Aborting
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 you look on the memory modules' stickers? Thanks! -- 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/
Re: [LKP] [sb_edac] 50d1bb93672: EDAC sbridge: ECC is disabled. Aborting
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 you look on the memory modules' stickers? Thanks! -- 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/
Re: [LKP] [sb_edac] 50d1bb93672: EDAC sbridge: ECC is disabled. Aborting
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 PoV, is: > > [ 12.506298] EDAC sbridge: ECC is disabled. Aborting > > This is what I want help from you to confirm whether it is abnormal. > > > Does it used to work before? If so, was there any BIOS setting change? > > Does the memories used on this machine have ECC? > > This is a high-end desktop, there is something as below in dmidecode > output. Is there some other way to tell whether the memories have ECC? > > Handle 0x0018, DMI type 16, 23 bytes > Physical Memory Array > Location: System Board Or Motherboard > Use: System Memory > Error Correction Type: Multi-bit ECC > Maximum Capacity: 128 GB > Error Information Handle: Not Provided > Number Of Devices: 4 > > Handle 0x001A, DMI type 17, 34 bytes > Memory Device > Array Handle: 0x0018 > Error Information Handle: Not Provided > Total Width: 72 bits > Data Width: 72 bits > Size: 8192 MB > Form Factor: DIMM > Set: None > Locator: DIMM_A1 > Bank Locator: CPU 0 > Type: > Type Detail: Synchronous > Speed: 1067 MHz > Manufacturer: 0x11 > Serial Number: Unknown > Asset Tag: Unknown > Part Number: Unknown > Rank: 1 > Configured Clock Speed: Unknown unfortunately with this I can't say :( Do you mind checking on EFI or maybe looking at the memory modules' part number? (sorry for the delay, was on vacations since 12/18) -- 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/
Re: [LKP] [sb_edac] 50d1bb93672: EDAC sbridge: ECC is disabled. Aborting
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 PoV, is: [ 12.506298] EDAC sbridge: ECC is disabled. Aborting This is what I want help from you to confirm whether it is abnormal. Does it used to work before? If so, was there any BIOS setting change? Does the memories used on this machine have ECC? This is a high-end desktop, there is something as below in dmidecode output. Is there some other way to tell whether the memories have ECC? Handle 0x0018, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 128 GB Error Information Handle: Not Provided Number Of Devices: 4 Handle 0x001A, DMI type 17, 34 bytes Memory Device Array Handle: 0x0018 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 72 bits Size: 8192 MB Form Factor: DIMM Set: None Locator: DIMM_A1 Bank Locator: CPU 0 Type: OUT OF SPEC Type Detail: Synchronous Speed: 1067 MHz Manufacturer: 0x11 Serial Number: Unknown Asset Tag: Unknown Part Number: Unknown Rank: 1 Configured Clock Speed: Unknown unfortunately with this I can't say :( Do you mind checking on EFI or maybe looking at the memory modules' part number? (sorry for the delay, was on vacations since 12/18) -- 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/
Re: [PATCH] sb_edac: Fix typo computing number of banks
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 > > drivers/edac/sb_edac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c > index 993e8b61c4b2..63aa6730e89e 100644 > --- a/drivers/edac/sb_edac.c > +++ b/drivers/edac/sb_edac.c > @@ -901,7 +901,7 @@ static int get_dimm_config(struct mem_ctl_info *mci) > else > edac_dbg(0, "Memory is unregistered\n"); > > - if (mtype == MEM_DDR4 || MEM_RDDR4) > + if (mtype == MEM_DDR4 || mtype == MEM_RDDR4) > banks = 16; > else > banks = 8; ACK -- 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/
Re: [PATCH] sb_edac: Fix typo computing number of banks
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 tony.l...@intel.com --- Not sure if Misha is shy, or just busy. But my attempt to get them to post their own patch didn't work drivers/edac/sb_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c index 993e8b61c4b2..63aa6730e89e 100644 --- a/drivers/edac/sb_edac.c +++ b/drivers/edac/sb_edac.c @@ -901,7 +901,7 @@ static int get_dimm_config(struct mem_ctl_info *mci) else edac_dbg(0, Memory is unregistered\n); - if (mtype == MEM_DDR4 || MEM_RDDR4) + if (mtype == MEM_DDR4 || mtype == MEM_RDDR4) banks = 16; else banks = 8; ACK -- 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/
Re: [PATCH] sb_edac: Add support for Broadwell-DE processor
Hi Tony,
On Mon, Nov 17, 2014 at 10:00:11AM -0800, Luck, Tony wrote:
> Broadwell-DE is the microserver version of next generation Xeon
> processors. A whole bunch of new PCIe device ids, but otherwise
> pretty much the same as Haswell.
>
> Signed-off-by: Tony Luck
>
> ---
>
> Mauro: Naming of routines and #defines follows the existing
> convention of only making new functions where changes are
> needed, and using older functions with names from previous
> generations where no changes are needed. Can you take this
> as-is for the next merge window and we can have a discussion
> about whether to have a massive re-naming to some "better"
> nomenclature in the coming months. More changes will be
> needed for Broadwell-EP and Broadwell-EX
>
> Also needs that Haswell TOLM fix I posted in October:
> http://www.spinics.net/lists/linux-edac/msg04109.html#.VGo3FHW9_CI
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index e9bb1af67c8d..5a140adb5191 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -261,6 +261,7 @@ enum type {
> SANDY_BRIDGE,
> IVY_BRIDGE,
> HASWELL,
> + BROADWELL,
> };
>
> struct sbridge_pvt;
> @@ -445,7 +446,7 @@ static const struct pci_id_table
> pci_dev_descr_ibridge_table[] = {
> * - each SMI channel interfaces with a scalable memory buffer
> * - each scalable memory buffer supports 4 DDR3/DDR4 channels, 3 DPC
> */
> -#define HASWELL_DDRCRCLKCONTROLS 0xa10
> +#define HASWELL_DDRCRCLKCONTROLS 0xa10 /* Ditto on Broadwell */
> #define HASWELL_HASYSDEFEATURE2 0x84
> #define PCI_DEVICE_ID_INTEL_HASWELL_IMC_VTD_MISC 0x2f28
> #define PCI_DEVICE_ID_INTEL_HASWELL_IMC_HA0 0x2fa0
> @@ -496,6 +497,44 @@ static const struct pci_id_table
> pci_dev_descr_haswell_table[] = {
> {0,}/* 0 terminated list. */
> };
>
> +/* Broadwell support */
> +/* DE processor:
> + * - 1 IMC
> + * - 2 DDR3 channels, 2 DPC per channel
> + */
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_VTD_MISC 0x6f28
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA00x6fa0
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TA 0x6fa8
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_THERMAL 0x6f71
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD0 0x6ffc
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD1 0x6ffd
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD0 0x6faa
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD1 0x6fab
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD2 0x6fac
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD3 0x6fad
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_DDRIO0 0x6faf
> +
> +static const struct pci_id_descr pci_dev_descr_broadwell[] = {
> + /* first item must be the HA */
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0, 0) },
> +
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD0, 0) },
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD1, 0) },
> +
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TA, 0)},
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_THERMAL, 0) },
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD0, 0) },
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD1, 0) },
> + { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_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's not optional here.
Doesn't matter much and we should get rid of one of the checks anyway.
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/
Re: [PATCH] sb_edac: Add support for Broadwell-DE processor
Hi Tony,
On Mon, Nov 17, 2014 at 10:00:11AM -0800, Luck, Tony wrote:
Broadwell-DE is the microserver version of next generation Xeon
processors. A whole bunch of new PCIe device ids, but otherwise
pretty much the same as Haswell.
Signed-off-by: Tony Luck tony.l...@intel.com
---
Mauro: Naming of routines and #defines follows the existing
convention of only making new functions where changes are
needed, and using older functions with names from previous
generations where no changes are needed. Can you take this
as-is for the next merge window and we can have a discussion
about whether to have a massive re-naming to some better
nomenclature in the coming months. More changes will be
needed for Broadwell-EP and Broadwell-EX
Also needs that Haswell TOLM fix I posted in October:
http://www.spinics.net/lists/linux-edac/msg04109.html#.VGo3FHW9_CI
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index e9bb1af67c8d..5a140adb5191 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -261,6 +261,7 @@ enum type {
SANDY_BRIDGE,
IVY_BRIDGE,
HASWELL,
+ BROADWELL,
};
struct sbridge_pvt;
@@ -445,7 +446,7 @@ static const struct pci_id_table
pci_dev_descr_ibridge_table[] = {
* - each SMI channel interfaces with a scalable memory buffer
* - each scalable memory buffer supports 4 DDR3/DDR4 channels, 3 DPC
*/
-#define HASWELL_DDRCRCLKCONTROLS 0xa10
+#define HASWELL_DDRCRCLKCONTROLS 0xa10 /* Ditto on Broadwell */
#define HASWELL_HASYSDEFEATURE2 0x84
#define PCI_DEVICE_ID_INTEL_HASWELL_IMC_VTD_MISC 0x2f28
#define PCI_DEVICE_ID_INTEL_HASWELL_IMC_HA0 0x2fa0
@@ -496,6 +497,44 @@ static const struct pci_id_table
pci_dev_descr_haswell_table[] = {
{0,}/* 0 terminated list. */
};
+/* Broadwell support */
+/* DE processor:
+ * - 1 IMC
+ * - 2 DDR3 channels, 2 DPC per channel
+ */
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_VTD_MISC 0x6f28
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA00x6fa0
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TA 0x6fa8
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_THERMAL 0x6f71
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD0 0x6ffc
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD1 0x6ffd
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD0 0x6faa
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD1 0x6fab
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD2 0x6fac
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD3 0x6fad
+#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_DDRIO0 0x6faf
+
+static const struct pci_id_descr pci_dev_descr_broadwell[] = {
+ /* first item must be the HA */
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0, 0) },
+
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD0, 0) },
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD1, 0) },
+
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TA, 0)},
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_THERMAL, 0) },
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD0, 0) },
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD1, 0) },
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_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's not optional here.
Doesn't matter much and we should get rid of one of the checks anyway.
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
Re: [PATCH] lib/flex_array: make build optional
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 > >> + help > >> +This option enables an implementation of flexible arrays which > >> +allows creating arrays of fixed size elements with an arbritrary > >> +size without requiring the single allocation of a contiguous area. > >> + > >> +See Documentation/flexible-arrays.txt > > > > Is there any reason to expose this to the user via Kconfig? > > > > No sane person would even turn it on if they don't need it. > > IOW, I think you should just make it: > > config FLEX_ARRAY > def_bool n Joe Pershes complained on a similar patch on making it default to 'n'. Will rework the patches this way. -- 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/
Re: [PATCH] lib/halfmd4: make build optional
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 indirectly anyway. -- 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/
[PATCH] lib/rhashtable: make build optional
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't be optionally built if CONFIG_NET is enabled) and netfilter_hash. This patch is useful for situations in which memory footprint is a concern and networking is not enabled. Cc: David S. Miller Cc: Fabian Frederick Cc: Geert Uytterhoeven Cc: Linus Torvalds Cc: Pablo Neira Ayuso Cc: Thomas Graf Cc: Ying Xue Cc: Josh Triplett Signed-off-by: Aristeu Rozanski --- lib/Kconfig | 6 ++ lib/Makefile | 4 +++- net/Kconfig | 1 + 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig b/lib/Kconfig index 108196c..d6b8879 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -369,6 +369,12 @@ config ASSOCIATIVE_ARRAY for more information. +config RHASH_TABLE + bool "Resizable hash table" + default y + help + Resizable, scalable and concurrent hash table implementation. + config HAS_IOMEM boolean depends on !NO_IOMEM diff --git a/lib/Makefile b/lib/Makefile index 53fd120..43d29ff 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -26,7 +26,7 @@ obj-y += bcd.o div64.o sort.o parser.o debug_locks.o random32.o \ bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ gcd.o lcm.o list_sort.o uuid.o iovec.o clz_ctz.o \ bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \ -percpu-refcount.o percpu_ida.o hash.o rhashtable.o +percpu-refcount.o percpu_ida.o hash.o obj-y += string_helpers.o obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o obj-y += kstrtox.o @@ -155,6 +155,8 @@ obj-$(CONFIG_GENERIC_NET_UTILS) += net_utils.o obj-$(CONFIG_STMP_DEVICE) += stmp_device.o +obj-$(CONFIG_RHASH_TABLE) += rhashtable.o + libfdt_files = fdt.o fdt_ro.o fdt_wip.o fdt_rw.o fdt_sw.o fdt_strerror.o \ fdt_empty_tree.o $(foreach file, $(libfdt_files), \ diff --git a/net/Kconfig b/net/Kconfig index 99815b5..d376630 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -7,6 +7,7 @@ menuconfig NET select NLATTR select GENERIC_NET_UTILS select BPF + select RHASH_TABLE ---help--- Unless you really know what you are doing, you should say Y here. The reason is that some programs need kernel networking support even -- 1.8.3.1 -- 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/
[PATCH] lib/halfmd4: make build optional
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 useful for situations in which memory footprint is a concern and those filesystems aren't used. Cc: Jan Kara Cc: Andrew Morton Cc: Andreas Dilger Cc: Paul Gortmaker Cc: Josh Triplett Signed-off-by: Aristeu Rozanski --- fs/ext3/Kconfig | 1 + fs/ext4/Kconfig | 1 + lib/Kconfig | 7 +++ lib/Makefile| 3 ++- 4 files changed, 11 insertions(+), 1 deletion(-) diff --git a/fs/ext3/Kconfig b/fs/ext3/Kconfig index e8c6ba0..a6ab4e8 100644 --- a/fs/ext3/Kconfig +++ b/fs/ext3/Kconfig @@ -1,6 +1,7 @@ config EXT3_FS tristate "Ext3 journalling file system support" select JBD + select HALF_MD4 help This is the journalling version of the Second extended file system (often called ext3), the de facto standard Linux file system diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig index efea5d5..cbb56ee 100644 --- a/fs/ext4/Kconfig +++ b/fs/ext4/Kconfig @@ -4,6 +4,7 @@ config EXT4_FS select CRC16 select CRYPTO select CRYPTO_CRC32C + select HALF_MD4 help This is the next generation of the ext3 filesystem. diff --git a/lib/Kconfig b/lib/Kconfig index 675920b..108196c 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -180,6 +180,13 @@ config CRC8 when they need to do cyclic redundancy check according CRC8 algorithm. Module will be called crc8. +config HALF_MD4 + bool "Half MD4 transform" + default y + help + This option enables a reduced (32 bit output) version of MD4 + transform. + config AUDIT_GENERIC bool depends on AUDIT && !AUDIT_ARCH diff --git a/lib/Makefile b/lib/Makefile index 9c12cbc..53fd120 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -22,7 +22,7 @@ lib-$(CONFIG_SMP) += cpumask.o lib-y += kobject.o klist.o obj-y += lockref.o -obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \ +obj-y += bcd.o div64.o sort.o parser.o debug_locks.o random32.o \ bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ gcd.o lcm.o list_sort.o uuid.o iovec.o clz_ctz.o \ bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \ @@ -74,6 +74,7 @@ obj-$(CONFIG_CRC7)+= crc7.o obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o obj-$(CONFIG_CRC8) += crc8.o obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o +obj-$(CONFIG_HALF_MD4) += halfmd4.o obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/ obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ -- 1.8.3.1 -- 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/
[PATCH] lib/flex_array: make build optional
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. This patch is useful for situations in which memory footprint is a concern and those features aren't used. Cc: Changli Gao Cc: Dave Hansen Cc: David Rientjes Cc: Eric Paris Cc: Hannes Frederic Sowa Cc: Jesse Gross Cc: Jonathan Corbet Cc: Paul Gortmaker Cc: Pravin Shelar Cc: Alexander Viro Cc: Josh Triplett Signed-off-by: Aristeu Rozanski --- fs/proc/Kconfig | 1 + lib/Kconfig | 10 ++ lib/Makefile | 3 ++- net/openvswitch/Kconfig | 1 + security/selinux/Kconfig | 1 + 5 files changed, 15 insertions(+), 1 deletion(-) diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig index 2183fcf..2d624b7 100644 --- a/fs/proc/Kconfig +++ b/fs/proc/Kconfig @@ -1,6 +1,7 @@ config PROC_FS bool "/proc file system support" if EXPERT default y + select FLEX_ARRAY help This is a virtual file system providing information about the status of the system. "Virtual" means that it doesn't take up any space on diff --git a/lib/Kconfig b/lib/Kconfig index 54cf309..675920b 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -432,6 +432,16 @@ config GLOB_SELFTEST module load) by a small amount, so you're welcome to play with it, but you probably don't need it. +config FLEX_ARRAY + bool "Flexible array" + default n + help + This option enables an implementation of flexible arrays which + allows creating arrays of fixed size elements with an arbritrary + size without requiring the single allocation of a contiguous area. + + See Documentation/flexible-arrays.txt + # # Netlink attribute parsing support is select'ed if needed # diff --git a/lib/Makefile b/lib/Makefile index 7512dc9..9c12cbc 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -24,7 +24,7 @@ obj-y += lockref.o obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \ bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ -gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \ +gcd.o lcm.o list_sort.o uuid.o iovec.o clz_ctz.o \ bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \ percpu-refcount.o percpu_ida.o hash.o rhashtable.o obj-y += string_helpers.o @@ -35,6 +35,7 @@ obj-$(CONFIG_TEST_LKM) += test_module.o obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o obj-$(CONFIG_TEST_BPF) += test_bpf.o obj-$(CONFIG_TEST_FIRMWARE) += test_firmware.o +obj-$(CONFIG_FLEX_ARRAY) += flex_array.o ifeq ($(CONFIG_DEBUG_KOBJECT),y) CFLAGS_kobject.o += -DDEBUG diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig index ba3bb82..1d979ce 100644 --- a/net/openvswitch/Kconfig +++ b/net/openvswitch/Kconfig @@ -5,6 +5,7 @@ config OPENVSWITCH tristate "Open vSwitch" select LIBCRC32C + select FLEX_ARRAY ---help--- Open vSwitch is a multilayer Ethernet switch targeted at virtualized environments. In addition to supporting a variety of features diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig index bca1b74..cfcc7c1 100644 --- a/security/selinux/Kconfig +++ b/security/selinux/Kconfig @@ -2,6 +2,7 @@ config SECURITY_SELINUX bool "NSA SELinux Support" depends on SECURITY_NETWORK && AUDIT && NET && INET select NETWORK_SECMARK + select FLEX_ARRAY default n help This selects NSA Security-Enhanced Linux (SELinux). -- 1.8.3.1 -- 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/
[PATCH] lib/flex_array: make build optional
From: Aristeu Rozanski aroza...@redhat.com 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. This patch is useful for situations in which memory footprint is a concern and those features aren't used. Cc: Changli Gao xiao...@gmail.com Cc: Dave Hansen d...@linux.vnet.ibm.com Cc: David Rientjes rient...@google.com Cc: Eric Paris epa...@redhat.com Cc: Hannes Frederic Sowa han...@stressinduktion.org Cc: Jesse Gross je...@nicira.com Cc: Jonathan Corbet cor...@lwn.net Cc: Paul Gortmaker paul.gortma...@windriver.com Cc: Pravin Shelar pshe...@nicira.com Cc: Alexander Viro v...@zeniv.linux.org.uk Cc: Josh Triplett j...@joshtriplett.org Signed-off-by: Aristeu Rozanski aroza...@redhat.com --- fs/proc/Kconfig | 1 + lib/Kconfig | 10 ++ lib/Makefile | 3 ++- net/openvswitch/Kconfig | 1 + security/selinux/Kconfig | 1 + 5 files changed, 15 insertions(+), 1 deletion(-) diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig index 2183fcf..2d624b7 100644 --- a/fs/proc/Kconfig +++ b/fs/proc/Kconfig @@ -1,6 +1,7 @@ config PROC_FS bool /proc file system support if EXPERT default y + select FLEX_ARRAY help This is a virtual file system providing information about the status of the system. Virtual means that it doesn't take up any space on diff --git a/lib/Kconfig b/lib/Kconfig index 54cf309..675920b 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -432,6 +432,16 @@ config GLOB_SELFTEST module load) by a small amount, so you're welcome to play with it, but you probably don't need it. +config FLEX_ARRAY + bool Flexible array + default n + help + This option enables an implementation of flexible arrays which + allows creating arrays of fixed size elements with an arbritrary + size without requiring the single allocation of a contiguous area. + + See Documentation/flexible-arrays.txt + # # Netlink attribute parsing support is select'ed if needed # diff --git a/lib/Makefile b/lib/Makefile index 7512dc9..9c12cbc 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -24,7 +24,7 @@ obj-y += lockref.o obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \ bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ -gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \ +gcd.o lcm.o list_sort.o uuid.o iovec.o clz_ctz.o \ bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \ percpu-refcount.o percpu_ida.o hash.o rhashtable.o obj-y += string_helpers.o @@ -35,6 +35,7 @@ obj-$(CONFIG_TEST_LKM) += test_module.o obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o obj-$(CONFIG_TEST_BPF) += test_bpf.o obj-$(CONFIG_TEST_FIRMWARE) += test_firmware.o +obj-$(CONFIG_FLEX_ARRAY) += flex_array.o ifeq ($(CONFIG_DEBUG_KOBJECT),y) CFLAGS_kobject.o += -DDEBUG diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig index ba3bb82..1d979ce 100644 --- a/net/openvswitch/Kconfig +++ b/net/openvswitch/Kconfig @@ -5,6 +5,7 @@ config OPENVSWITCH tristate Open vSwitch select LIBCRC32C + select FLEX_ARRAY ---help--- Open vSwitch is a multilayer Ethernet switch targeted at virtualized environments. In addition to supporting a variety of features diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig index bca1b74..cfcc7c1 100644 --- a/security/selinux/Kconfig +++ b/security/selinux/Kconfig @@ -2,6 +2,7 @@ config SECURITY_SELINUX bool NSA SELinux Support depends on SECURITY_NETWORK AUDIT NET INET select NETWORK_SECMARK + select FLEX_ARRAY default n help This selects NSA Security-Enhanced Linux (SELinux). -- 1.8.3.1 -- 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/
[PATCH] lib/halfmd4: make build optional
From: Aristeu Rozanski aroza...@redhat.com 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 useful for situations in which memory footprint is a concern and those filesystems aren't used. Cc: Jan Kara j...@suse.cz Cc: Andrew Morton a...@linux-foundation.org Cc: Andreas Dilger adilger.ker...@dilger.ca Cc: Paul Gortmaker paul.gortma...@windriver.com Cc: Josh Triplett j...@joshtriplett.org Signed-off-by: Aristeu Rozanski aroza...@redhat.com --- fs/ext3/Kconfig | 1 + fs/ext4/Kconfig | 1 + lib/Kconfig | 7 +++ lib/Makefile| 3 ++- 4 files changed, 11 insertions(+), 1 deletion(-) diff --git a/fs/ext3/Kconfig b/fs/ext3/Kconfig index e8c6ba0..a6ab4e8 100644 --- a/fs/ext3/Kconfig +++ b/fs/ext3/Kconfig @@ -1,6 +1,7 @@ config EXT3_FS tristate Ext3 journalling file system support select JBD + select HALF_MD4 help This is the journalling version of the Second extended file system (often called ext3), the de facto standard Linux file system diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig index efea5d5..cbb56ee 100644 --- a/fs/ext4/Kconfig +++ b/fs/ext4/Kconfig @@ -4,6 +4,7 @@ config EXT4_FS select CRC16 select CRYPTO select CRYPTO_CRC32C + select HALF_MD4 help This is the next generation of the ext3 filesystem. diff --git a/lib/Kconfig b/lib/Kconfig index 675920b..108196c 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -180,6 +180,13 @@ config CRC8 when they need to do cyclic redundancy check according CRC8 algorithm. Module will be called crc8. +config HALF_MD4 + bool Half MD4 transform + default y + help + This option enables a reduced (32 bit output) version of MD4 + transform. + config AUDIT_GENERIC bool depends on AUDIT !AUDIT_ARCH diff --git a/lib/Makefile b/lib/Makefile index 9c12cbc..53fd120 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -22,7 +22,7 @@ lib-$(CONFIG_SMP) += cpumask.o lib-y += kobject.o klist.o obj-y += lockref.o -obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \ +obj-y += bcd.o div64.o sort.o parser.o debug_locks.o random32.o \ bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ gcd.o lcm.o list_sort.o uuid.o iovec.o clz_ctz.o \ bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \ @@ -74,6 +74,7 @@ obj-$(CONFIG_CRC7)+= crc7.o obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o obj-$(CONFIG_CRC8) += crc8.o obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o +obj-$(CONFIG_HALF_MD4) += halfmd4.o obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/ obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ -- 1.8.3.1 -- 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/
[PATCH] lib/rhashtable: make build optional
From: Aristeu Rozanski aroza...@redhat.com 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't be optionally built if CONFIG_NET is enabled) and netfilter_hash. This patch is useful for situations in which memory footprint is a concern and networking is not enabled. Cc: David S. Miller da...@davemloft.net Cc: Fabian Frederick f...@skynet.be Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: Linus Torvalds torva...@linux-foundation.org Cc: Pablo Neira Ayuso pa...@netfilter.org Cc: Thomas Graf tg...@suug.ch Cc: Ying Xue ying@windriver.com Cc: Josh Triplett j...@joshtriplett.org Signed-off-by: Aristeu Rozanski aroza...@redhat.com --- lib/Kconfig | 6 ++ lib/Makefile | 4 +++- net/Kconfig | 1 + 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig b/lib/Kconfig index 108196c..d6b8879 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -369,6 +369,12 @@ config ASSOCIATIVE_ARRAY for more information. +config RHASH_TABLE + bool Resizable hash table + default y + help + Resizable, scalable and concurrent hash table implementation. + config HAS_IOMEM boolean depends on !NO_IOMEM diff --git a/lib/Makefile b/lib/Makefile index 53fd120..43d29ff 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -26,7 +26,7 @@ obj-y += bcd.o div64.o sort.o parser.o debug_locks.o random32.o \ bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ gcd.o lcm.o list_sort.o uuid.o iovec.o clz_ctz.o \ bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \ -percpu-refcount.o percpu_ida.o hash.o rhashtable.o +percpu-refcount.o percpu_ida.o hash.o obj-y += string_helpers.o obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o obj-y += kstrtox.o @@ -155,6 +155,8 @@ obj-$(CONFIG_GENERIC_NET_UTILS) += net_utils.o obj-$(CONFIG_STMP_DEVICE) += stmp_device.o +obj-$(CONFIG_RHASH_TABLE) += rhashtable.o + libfdt_files = fdt.o fdt_ro.o fdt_wip.o fdt_rw.o fdt_sw.o fdt_strerror.o \ fdt_empty_tree.o $(foreach file, $(libfdt_files), \ diff --git a/net/Kconfig b/net/Kconfig index 99815b5..d376630 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -7,6 +7,7 @@ menuconfig NET select NLATTR select GENERIC_NET_UTILS select BPF + select RHASH_TABLE ---help--- Unless you really know what you are doing, you should say Y here. The reason is that some programs need kernel networking support even -- 1.8.3.1 -- 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/
Re: [PATCH] lib/halfmd4: make build optional
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 indirectly anyway. -- 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/
Re: [PATCH] lib/flex_array: make build optional
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 + help +This option enables an implementation of flexible arrays which +allows creating arrays of fixed size elements with an arbritrary +size without requiring the single allocation of a contiguous area. + +See Documentation/flexible-arrays.txt Is there any reason to expose this to the user via Kconfig? No sane person would even turn it on if they don't need it. IOW, I think you should just make it: config FLEX_ARRAY def_bool n Joe Pershes complained on a similar patch on making it default to 'n'. Will rework the patches this way. -- 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/
Re: [PATCH 3.18] tiny: rename ENABLE_DEV_COREDUMP to ALLOW_DEV_COREDUMP
On Thu, Oct 30, 2014 at 10:00:35AM +0100, Johannes Berg wrote: > From: Johannes Berg > > The ENABLE_DEV_COREDUMP option is misleading as it implies that > it gets the framework enabled, this isn't true it just allows it > to get enabled if a driver needs it. > > Rename 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/Kconfig b/drivers/base/Kconfig > index 99d30729d11e..e9f96afe920d 100644 > --- a/drivers/base/Kconfig > +++ b/drivers/base/Kconfig > @@ -171,8 +171,8 @@ config WANT_DEV_COREDUMP > Drivers should "select" this option if they desire to use the > device coredump mechanism. > > -config ENABLE_DEV_COREDUMP > - bool "Enable device coredump" if EXPERT > +config ALLOW_DEV_COREDUMP > + bool "Allow device coredump" if EXPERT > default y > help > This option controls if the device coredump mechanism is available or > @@ -187,7 +187,7 @@ config ENABLE_DEV_COREDUMP > config DEV_COREDUMP > bool > default y if WANT_DEV_COREDUMP > - depends on ENABLE_DEV_COREDUMP > + depends on ALLOW_DEV_COREDUMP > > config DEBUG_DRIVER > bool "Driver Core verbose debug messages" > -- > 2.1.0 > > -- 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/
Re: [PATCH 3.18] tiny: rename ENABLE_DEV_COREDUMP to ALLOW_DEV_COREDUMP
On Thu, Oct 30, 2014 at 10:00:35AM +0100, Johannes Berg wrote: From: Johannes Berg johannes.b...@intel.com The ENABLE_DEV_COREDUMP option is misleading as it implies that it gets the framework enabled, this isn't true it just allows it to get enabled if a driver needs it. Rename it to ALLOW_DEV_COREDUMP to better capture its semantics. Sounds much better! Acked-by: Aristeu Rozanski a...@redhat.com Signed-off-by: Johannes Berg johannes.b...@intel.com --- drivers/base/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 99d30729d11e..e9f96afe920d 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -171,8 +171,8 @@ config WANT_DEV_COREDUMP Drivers should select this option if they desire to use the device coredump mechanism. -config ENABLE_DEV_COREDUMP - bool Enable device coredump if EXPERT +config ALLOW_DEV_COREDUMP + bool Allow device coredump if EXPERT default y help This option controls if the device coredump mechanism is available or @@ -187,7 +187,7 @@ config ENABLE_DEV_COREDUMP config DEV_COREDUMP bool default y if WANT_DEV_COREDUMP - depends on ENABLE_DEV_COREDUMP + depends on ALLOW_DEV_COREDUMP config DEBUG_DRIVER bool Driver Core verbose debug messages -- 2.1.0 -- 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/
[PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
It's desirable for allnconfig and tinyconfig targets to result in the least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to switch off DEV_COREDUMP regardless if any drivers select WANT_DEV_COREDUMP. This patch renames the 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 --- drivers/base/Kconfig | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 134f763..99d3072 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -171,20 +171,23 @@ config WANT_DEV_COREDUMP Drivers should "select" this option if they desire to use the device coredump mechanism. -config DISABLE_DEV_COREDUMP - bool "Disable device coredump" if EXPERT +config ENABLE_DEV_COREDUMP + bool "Enable device coredump" if EXPERT + default y help - Disable the device coredump mechanism despite drivers wanting to - use it; this allows for more sensitive systems or systems that - don't want to ever access the information to not have the code, - nor keep any data. + This option controls if the device coredump mechanism is available or + not; if disabled, the mechanism will be omitted even if drivers that + can use it are enabled. + Say 'N' for more sensitive systems or systems that don't want + to ever access the information to not have the code, nor keep any + data. - If unsure, say N. + If unsure, say Y. config DEV_COREDUMP bool default y if WANT_DEV_COREDUMP - depends on !DISABLE_DEV_COREDUMP + depends on ENABLE_DEV_COREDUMP config DEBUG_DRIVER bool "Driver Core verbose debug messages" -- 1.8.3.1 -- 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/
[PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
(This time Cc'ing Johannes) It's desirable for allnconfig and tinyconfig targets to result in the least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to switch off DEV_COREDUMP regardless if any drivers select WANT_DEV_COREDUMP. This patch renames the 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/Kconfig index 134f763..99d3072 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -171,20 +171,23 @@ config WANT_DEV_COREDUMP Drivers should "select" this option if they desire to use the device coredump mechanism. -config DISABLE_DEV_COREDUMP - bool "Disable device coredump" if EXPERT +config ENABLE_DEV_COREDUMP + bool "Enable device coredump" if EXPERT + default y help - Disable the device coredump mechanism despite drivers wanting to - use it; this allows for more sensitive systems or systems that - don't want to ever access the information to not have the code, - nor keep any data. + This option controls if the device coredump mechanism is available or + not; if disabled, the mechanism will be omitted even if drivers that + can use it are enabled. + Say 'N' for more sensitive systems or systems that don't want + to ever access the information to not have the code, nor keep any + data. - If unsure, say N. + If unsure, say Y. config DEV_COREDUMP bool default y if WANT_DEV_COREDUMP - depends on !DISABLE_DEV_COREDUMP + depends on ENABLE_DEV_COREDUMP config DEBUG_DRIVER bool "Driver Core verbose debug messages" -- 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/
Re: [PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
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 "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/
Re: [PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
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 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/
[PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
(This time Cc'ing Johannes) It's desirable for allnconfig and tinyconfig targets to result in the least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to switch off DEV_COREDUMP regardless if any drivers select WANT_DEV_COREDUMP. This patch renames the option to ENABLE_DEV_COREDUMP and setting it to 'n' (as in allnconfig or tinyconfig) will effectively disable device coredump. Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Josh Triplett j...@joshtriplett.org Cc: Johannes Berg johan...@sipsolutions.net Reviewed-by: Josh Triplett j...@joshtriplett.org Signed-off-by: Aristeu Rozanski aroza...@redhat.com diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 134f763..99d3072 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -171,20 +171,23 @@ config WANT_DEV_COREDUMP Drivers should select this option if they desire to use the device coredump mechanism. -config DISABLE_DEV_COREDUMP - bool Disable device coredump if EXPERT +config ENABLE_DEV_COREDUMP + bool Enable device coredump if EXPERT + default y help - Disable the device coredump mechanism despite drivers wanting to - use it; this allows for more sensitive systems or systems that - don't want to ever access the information to not have the code, - nor keep any data. + This option controls if the device coredump mechanism is available or + not; if disabled, the mechanism will be omitted even if drivers that + can use it are enabled. + Say 'N' for more sensitive systems or systems that don't want + to ever access the information to not have the code, nor keep any + data. - If unsure, say N. + If unsure, say Y. config DEV_COREDUMP bool default y if WANT_DEV_COREDUMP - depends on !DISABLE_DEV_COREDUMP + depends on ENABLE_DEV_COREDUMP config DEBUG_DRIVER bool Driver Core verbose debug messages -- 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/
[PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
It's desirable for allnconfig and tinyconfig targets to result in the least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to switch off DEV_COREDUMP regardless if any drivers select WANT_DEV_COREDUMP. This patch renames the option to ENABLE_DEV_COREDUMP and setting it to 'n' (as in allnconfig or tinyconfig) will effectively disable device coredump. Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Josh Triplett j...@joshtriplett.org Cc: Johannes Berg johan...@sipsolutions.net Reviewed-by: Josh Triplett j...@joshtriplett.org Signed-off-by: Aristeu Rozanski aroza...@redhat.com --- drivers/base/Kconfig | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 134f763..99d3072 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -171,20 +171,23 @@ config WANT_DEV_COREDUMP Drivers should select this option if they desire to use the device coredump mechanism. -config DISABLE_DEV_COREDUMP - bool Disable device coredump if EXPERT +config ENABLE_DEV_COREDUMP + bool Enable device coredump if EXPERT + default y help - Disable the device coredump mechanism despite drivers wanting to - use it; this allows for more sensitive systems or systems that - don't want to ever access the information to not have the code, - nor keep any data. + This option controls if the device coredump mechanism is available or + not; if disabled, the mechanism will be omitted even if drivers that + can use it are enabled. + Say 'N' for more sensitive systems or systems that don't want + to ever access the information to not have the code, nor keep any + data. - If unsure, say N. + If unsure, say Y. config DEV_COREDUMP bool default y if WANT_DEV_COREDUMP - depends on !DISABLE_DEV_COREDUMP + depends on ENABLE_DEV_COREDUMP config DEBUG_DRIVER bool Driver Core verbose debug messages -- 1.8.3.1 -- 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/
[PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
It's desirable for allnconfig and tinyconfig targets to result in the least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to switch off DEV_COREDUMP regardless if any drivers select WANT_DEV_COREDUMP. This patch renames the 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 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/base/Kconfig +++ b/drivers/base/Kconfig @@ -171,20 +171,23 @@ config WANT_DEV_COREDUMP Drivers should "select" this option if they desire to use the device coredump mechanism. -config DISABLE_DEV_COREDUMP - bool "Disable device coredump" if EXPERT +config ENABLE_DEV_COREDUMP + bool "Enable device coredump" if EXPERT + default y help - Disable the device coredump mechanism despite drivers wanting to - use it; this allows for more sensitive systems or systems that - don't want to ever access the information to not have the code, - nor keep any data. + This option controls if the device coredump mechanism is available or + not; if disabled, the mechanism will be omitted even if drivers that + can use it are enabled. + Say 'N' for more sensitive systems or systems that don't want + to ever access the information to not have the code, nor keep any + data. - If unsure, say N. + If unsure, say Y. config DEV_COREDUMP bool default y if WANT_DEV_COREDUMP - depends on !DISABLE_DEV_COREDUMP + depends on ENABLE_DEV_COREDUMP config DEBUG_DRIVER bool "Driver Core verbose debug messages" -- 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/
[PATCH] tiny: reverse logic for DISABLE_DEV_COREDUMP
It's desirable for allnconfig and tinyconfig targets to result in the least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to switch off DEV_COREDUMP regardless if any drivers select WANT_DEV_COREDUMP. This patch renames the option to ENABLE_DEV_COREDUMP and setting it to 'n' (as in allnconfig or tinyconfig) will effectively disable device coredump. Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Josh Triplett j...@joshtriplett.org Reviewed-by: Josh Triplett j...@joshtriplett.org Signed-off-by: Aristeu Rozanski aroza...@redhat.com diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 134f763..63a5702 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -171,20 +171,23 @@ config WANT_DEV_COREDUMP Drivers should select this option if they desire to use the device coredump mechanism. -config DISABLE_DEV_COREDUMP - bool Disable device coredump if EXPERT +config ENABLE_DEV_COREDUMP + bool Enable device coredump if EXPERT + default y help - Disable the device coredump mechanism despite drivers wanting to - use it; this allows for more sensitive systems or systems that - don't want to ever access the information to not have the code, - nor keep any data. + This option controls if the device coredump mechanism is available or + not; if disabled, the mechanism will be omitted even if drivers that + can use it are enabled. + Say 'N' for more sensitive systems or systems that don't want + to ever access the information to not have the code, nor keep any + data. - If unsure, say N. + If unsure, say Y. config DEV_COREDUMP bool default y if WANT_DEV_COREDUMP - depends on !DISABLE_DEV_COREDUMP + depends on ENABLE_DEV_COREDUMP config DEBUG_DRIVER bool Driver Core verbose debug messages -- 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/
Re: [RESEND][PATCH] userns: use marco instead of magic number for max userns level
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 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/
Re: [RESEND][PATCH] userns: use marco instead of magic number for max userns level
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 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/
Re: [PATCH] sb_edac: avoid INTERNAL ERROR message in EDAC with unspecified channel
On Fri, Sep 05, 2014 at 02:28:47PM -0500, Seth Jennings wrote:
> Intel IA32 SDM Table 15-14 defines channel 0xf as 'not specified', but
> EDAC doesn't know about this and returns and INTERNAL ERROR when the
> channel is greater than NUM_CHANNELS:
>
> kernel: [ 1538.886456] CPU 0: Machine Check Exception: 0 Bank 1:
> 949f
> kernel: [ 1538.886669] TSC 2bc68b22e7e812 ADDR 46dae7000 MISC 0 PROCESSOR
> 0:306e4 TIME 1390414572 SOCKET 0 APIC 0
> kernel: [ 1538.971948] EDAC MC1: INTERNAL ERROR: channel value is out of
> range (15 >= 4)
> kernel: [ 1538.972203] EDAC MC1: 0 CE memory read error on unknown memory
> (slot:0 page:0x46dae7 offset:0x0 grain:0 syndrome:0x0 - area:DRAM
> err_code::009f socket:1 channel_mask:1 rank:0)
>
> This commit changes sb_edac to forward a channel of -1 to EDAC if the
> channel 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: Aristeu Rozanski
> Cc: linux-e...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/edac/sb_edac.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index 0034c48..07efed4 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -283,8 +283,9 @@ static const u32 correrrthrsld[] = {
> * sbridge structs
> */
>
> -#define NUM_CHANNELS 4
> -#define MAX_DIMMS3 /* Max DIMMS per channel */
> +#define NUM_CHANNELS 4
> +#define MAX_DIMMS3 /* Max DIMMS per channel */
> +#define CHANNEL_UNSPECIFIED 0xf /* Intel IA32 SDM 15-14 */
>
> enum type {
> SANDY_BRIDGE,
> @@ -1991,6 +1992,9 @@ static void sbridge_mce_output_error(struct
> mem_ctl_info *mci,
>
> /* FIXME: need support for channel mask */
>
> + if (channel == CHANNEL_UNSPECIFIED)
> + channel = -1;
> +
> /* Call the helper to output message */
> edac_mc_handle_error(tp_event, mci, core_err_cnt,
>m->addr >> PAGE_SHIFT, m->addr & ~PAGE_MASK, 0,
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/
Re: [PATCH 2/2] sb_edac: Claim a different PCI device
On Thu, Aug 14, 2014 at 02:45:41PM -0700, Andy Lutomirski wrote:
> sb_edac controls a large number of different PCI functions. Rather
> than registering as a normal PCI driver for all of them, it
> registers for just one so that it gets probed and, at probe time, it
> looks for all the others.
>
> Coincidentally, the device it registers for also contains the SMBUS
> registers, so the PCI core will refuse to probe both sb_edac and a
> future iMC SMBUS driver. The drivers don't actually conflict, so
> just change sb_edac's device table to probe a different device.
>
> An alternative fix would be to merge the two drivers, but sb_edac
> will also refuse to load on non-ECC systems, whereas i2c_imc would
> still be useful without ECC.
>
> The only user-visible change should be that sb_edac appears to bind
> a different device.
>
> Cc: Mauro Carvalho Chehab
> Cc: Rui Wang
> Signed-off-by: Andy Lutomirski
> ---
> drivers/edac/sb_edac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index a2597e9313c6..e3bc2cced580 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -432,7 +432,7 @@ static const struct pci_id_table
> pci_dev_descr_ibridge_table[] = {
> * pci_device_id table for which devices we are looking for
> */
> static const struct pci_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,}/* 0 terminated list. */
> };
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/
Re: [PATCH 1/2] Move Intel SNB device ids from sb_edac to pci_ids.h
On Thu, Aug 14, 2014 at 02:45:40PM -0700, Andy Lutomirski wrote:
> The i2c_imc driver will use two of them, and moving only part of
> the list seems messier.
>
> Cc: Mauro Carvalho Chehab
> Cc: Rui Wang
> Signed-off-by: Andy Lutomirski
> ---
> drivers/edac/sb_edac.c | 30 --
> include/linux/pci_ids.h | 15 +++
> 2 files changed, 15 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index deea0dcb..a2597e9313c6 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -52,36 +52,6 @@ static int probed;
> #define GET_BITFIELD(v, lo, hi) \
> (((v) & GENMASK_ULL(hi, lo)) >> (lo))
>
> -/*
> - * sbridge Memory Controller Registers
> - */
> -
> -/*
> - * FIXME: For now, let's order by device function, as it makes
> - * easier for driver's development process. This table should be
> - * moved to pci_id.h when submitted upstream
> - */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD0 0x3cf4 /* 12.6 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD1 0x3cf6 /* 12.7 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_BR 0x3cf5 /* 13.6 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0 0x3ca0 /* 14.0 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA 0x3ca8 /* 15.0 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_RAS 0x3c71 /* 15.1 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0 0x3caa /* 15.2 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD1 0x3cab /* 15.3 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD2 0x3cac /* 15.4 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD3 0x3cad /* 15.5 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO0x3cb8 /* 17.0 */
> -
> - /*
> - * Currently, unused, but will be needed in the future
> - * implementations, as they hold the error counters
> - */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR0 0x3c72 /* 16.2 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR1 0x3c73 /* 16.3 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR2 0x3c76 /* 16.6 */
> -#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR3 0x3c77 /* 16.7 */
> -
> /* Devices 12 Function 6, Offsets 0x80 to 0xcc */
> static const u32 sbridge_dram_rule[] = {
> 0x80, 0x88, 0x90, 0x98, 0xa0,
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 7fa31731c854..e0e6801c3d80 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2816,7 +2816,22 @@
> #define PCI_DEVICE_ID_INTEL_UNC_R2PCIE 0x3c43
> #define PCI_DEVICE_ID_INTEL_UNC_R3QPI0 0x3c44
> #define PCI_DEVICE_ID_INTEL_UNC_R3QPI1 0x3c45
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_RAS 0x3c71 /* 15.1 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR0 0x3c72 /* 16.2 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR1 0x3c73 /* 16.3 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR2 0x3c76 /* 16.6 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR3 0x3c77 /* 16.7 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0 0x3ca0 /* 14.0 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA 0x3ca8 /* 15.0 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0 0x3caa /* 15.2 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD1 0x3cab /* 15.3 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD2 0x3cac /* 15.4 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_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 */
> +#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD1 0x3cf6 /* 12.7 */
> #define PCI_DEVICE_ID_INTEL_IOAT_SNB 0x402f
> #define PCI_DEVICE_ID_INTEL_5100_16 0x65f0
> #define PCI_DEVICE_ID_INTEL_5100_19 0x65f3
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/
Re: [PATCH 1/2] Move Intel SNB device ids from sb_edac to pci_ids.h
On Thu, Aug 14, 2014 at 02:45:40PM -0700, Andy Lutomirski wrote:
The i2c_imc driver will use two of them, and moving only part of
the list seems messier.
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Rui Wang ruiv.w...@gmail.com
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/edac/sb_edac.c | 30 --
include/linux/pci_ids.h | 15 +++
2 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index deea0dcb..a2597e9313c6 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -52,36 +52,6 @@ static int probed;
#define GET_BITFIELD(v, lo, hi) \
(((v) GENMASK_ULL(hi, lo)) (lo))
-/*
- * sbridge Memory Controller Registers
- */
-
-/*
- * FIXME: For now, let's order by device function, as it makes
- * easier for driver's development process. This table should be
- * moved to pci_id.h when submitted upstream
- */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD0 0x3cf4 /* 12.6 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD1 0x3cf6 /* 12.7 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_BR 0x3cf5 /* 13.6 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0 0x3ca0 /* 14.0 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA 0x3ca8 /* 15.0 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_RAS 0x3c71 /* 15.1 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0 0x3caa /* 15.2 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD1 0x3cab /* 15.3 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD2 0x3cac /* 15.4 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD3 0x3cad /* 15.5 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO0x3cb8 /* 17.0 */
-
- /*
- * Currently, unused, but will be needed in the future
- * implementations, as they hold the error counters
- */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR0 0x3c72 /* 16.2 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR1 0x3c73 /* 16.3 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR2 0x3c76 /* 16.6 */
-#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR3 0x3c77 /* 16.7 */
-
/* Devices 12 Function 6, Offsets 0x80 to 0xcc */
static const u32 sbridge_dram_rule[] = {
0x80, 0x88, 0x90, 0x98, 0xa0,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 7fa31731c854..e0e6801c3d80 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2816,7 +2816,22 @@
#define PCI_DEVICE_ID_INTEL_UNC_R2PCIE 0x3c43
#define PCI_DEVICE_ID_INTEL_UNC_R3QPI0 0x3c44
#define PCI_DEVICE_ID_INTEL_UNC_R3QPI1 0x3c45
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_RAS 0x3c71 /* 15.1 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR0 0x3c72 /* 16.2 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR1 0x3c73 /* 16.3 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR2 0x3c76 /* 16.6 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_ERR3 0x3c77 /* 16.7 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0 0x3ca0 /* 14.0 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA 0x3ca8 /* 15.0 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0 0x3caa /* 15.2 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD1 0x3cab /* 15.3 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD2 0x3cac /* 15.4 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_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 */
+#define PCI_DEVICE_ID_INTEL_SBRIDGE_SAD1 0x3cf6 /* 12.7 */
#define PCI_DEVICE_ID_INTEL_IOAT_SNB 0x402f
#define PCI_DEVICE_ID_INTEL_5100_16 0x65f0
#define PCI_DEVICE_ID_INTEL_5100_19 0x65f3
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
Re: [PATCH 2/2] sb_edac: Claim a different PCI device
On Thu, Aug 14, 2014 at 02:45:41PM -0700, Andy Lutomirski wrote:
sb_edac controls a large number of different PCI functions. Rather
than registering as a normal PCI driver for all of them, it
registers for just one so that it gets probed and, at probe time, it
looks for all the others.
Coincidentally, the device it registers for also contains the SMBUS
registers, so the PCI core will refuse to probe both sb_edac and a
future iMC SMBUS driver. The drivers don't actually conflict, so
just change sb_edac's device table to probe a different device.
An alternative fix would be to merge the two drivers, but sb_edac
will also refuse to load on non-ECC systems, whereas i2c_imc would
still be useful without ECC.
The only user-visible change should be that sb_edac appears to bind
a different device.
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Rui Wang ruiv.w...@gmail.com
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/edac/sb_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index a2597e9313c6..e3bc2cced580 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -432,7 +432,7 @@ static const struct pci_id_table
pci_dev_descr_ibridge_table[] = {
* pci_device_id table for which devices we are looking for
*/
static const struct pci_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,}/* 0 terminated list. */
};
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
Re: [PATCH] sb_edac: avoid INTERNAL ERROR message in EDAC with unspecified channel
On Fri, Sep 05, 2014 at 02:28:47PM -0500, Seth Jennings wrote:
Intel IA32 SDM Table 15-14 defines channel 0xf as 'not specified', but
EDAC doesn't know about this and returns and INTERNAL ERROR when the
channel is greater than NUM_CHANNELS:
kernel: [ 1538.886456] CPU 0: Machine Check Exception: 0 Bank 1:
949f
kernel: [ 1538.886669] TSC 2bc68b22e7e812 ADDR 46dae7000 MISC 0 PROCESSOR
0:306e4 TIME 1390414572 SOCKET 0 APIC 0
kernel: [ 1538.971948] EDAC MC1: INTERNAL ERROR: channel value is out of
range (15 = 4)
kernel: [ 1538.972203] EDAC MC1: 0 CE memory read error on unknown memory
(slot:0 page:0x46dae7 offset:0x0 grain:0 syndrome:0x0 - area:DRAM
err_code::009f socket:1 channel_mask:1 rank:0)
This commit changes sb_edac to forward a channel of -1 to EDAC if the
channel 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 sjenn...@redhat.com
Cc: Aristeu Rozanski a...@redhat.com
Cc: linux-e...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/edac/sb_edac.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 0034c48..07efed4 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -283,8 +283,9 @@ static const u32 correrrthrsld[] = {
* sbridge structs
*/
-#define NUM_CHANNELS 4
-#define MAX_DIMMS3 /* Max DIMMS per channel */
+#define NUM_CHANNELS 4
+#define MAX_DIMMS3 /* Max DIMMS per channel */
+#define CHANNEL_UNSPECIFIED 0xf /* Intel IA32 SDM 15-14 */
enum type {
SANDY_BRIDGE,
@@ -1991,6 +1992,9 @@ static void sbridge_mce_output_error(struct
mem_ctl_info *mci,
/* FIXME: need support for channel mask */
+ if (channel == CHANNEL_UNSPECIFIED)
+ channel = -1;
+
/* Call the helper to output message */
edac_mc_handle_error(tp_event, mci, core_err_cnt,
m-addr PAGE_SHIFT, m-addr ~PAGE_MASK, 0,
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
Re: [PATCH V4 0/8] namespaces: log namespaces per task
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 records from constituent > hosts to build an audit trail of a container. since you're introducing a brand new serial number to make it unique across different procfs mounts, why not instead of a simple counter, use the hash output of say, $hostname-$creation_time-$random? Or perhaps get a short hash of the hostname (generated once whenever hostname is set) and append the serial number you're implementing? It'd be way less human readable than your current proposal but it'd be unique "globally" (as long you don't have machines with the same hostname migrating containers between them), allowing the migrated namespaces to retain their unique identification across audit logs. It'd of course be way more costly than just using an atomic counter, but could be useful to anything that needs to refer to a namespace and could be migrated to another machine. What you think? Sounds too crazy? :) -- 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/
Re: [PATCH V4 0/8] namespaces: log namespaces per task
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 records from constituent hosts to build an audit trail of a container. since you're introducing a brand new serial number to make it unique across different procfs mounts, why not instead of a simple counter, use the hash output of say, $hostname-$creation_time-$random? Or perhaps get a short hash of the hostname (generated once whenever hostname is set) and append the serial number you're implementing? It'd be way less human readable than your current proposal but it'd be unique globally (as long you don't have machines with the same hostname migrating containers between them), allowing the migrated namespaces to retain their unique identification across audit logs. It'd of course be way more costly than just using an atomic counter, but could be useful to anything that needs to refer to a namespace and could be migrated to another machine. What you think? Sounds too crazy? :) -- 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/
Re: [PATCH] Revert "Input: wacom - testing result shows get_report is unnecessary."
On Fri, Jun 13, 2014 at 04:32:18PM -0400, Benjamin Tissoires wrote: > This reverts commit 1b2faaf7e219fc2905d75afcd4c815e5d39eda80. > > The Intuos4 series presents a bug in which it hangs if it receives > a set feature command while switching to the enhanced mode. > This bug is triggered when plugging an Intuos 4 while having > a gnome user session up and running. > > Signed-off-by: Benjamin Tissoires > --- > > Hi Aris, > > actually, you bisected the bug, so can I consider that I have your > signed-off-by? Yes, my apologies, I ended up losing 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 100644 > --- a/drivers/input/tablet/wacom_sys.c > +++ b/drivers/input/tablet/wacom_sys.c > @@ -536,6 +536,9 @@ static int wacom_set_device_mode(struct usb_interface > *intf, int report_id, int > > error = wacom_set_report(intf, WAC_HID_FEATURE_REPORT, >report_id, rep_data, length, 1); > + if (error >= 0) > + error = wacom_get_report(intf, WAC_HID_FEATURE_REPORT, > + report_id, rep_data, length, > 1); > } while ((error < 0 || rep_data[1] != mode) && limit++ < > WAC_MSG_RETRIES); > > kfree(rep_data); > -- > 1.9.0 > -- 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/
Re: [PATCH] Revert Input: wacom - testing result shows get_report is unnecessary.
On Fri, Jun 13, 2014 at 04:32:18PM -0400, Benjamin Tissoires wrote: This reverts commit 1b2faaf7e219fc2905d75afcd4c815e5d39eda80. The Intuos4 series presents a bug in which it hangs if it receives a set feature command while switching to the enhanced mode. This bug is triggered when plugging an Intuos 4 while having a gnome user session up and running. Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com --- Hi Aris, actually, you bisected the bug, so can I consider that I have your signed-off-by? Yes, my apologies, I ended up losing track of this and didn't send earlier. Signed-off-by: Aristeu Rozanski a...@redhat.com 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 100644 --- a/drivers/input/tablet/wacom_sys.c +++ b/drivers/input/tablet/wacom_sys.c @@ -536,6 +536,9 @@ static int wacom_set_device_mode(struct usb_interface *intf, int report_id, int error = wacom_set_report(intf, WAC_HID_FEATURE_REPORT, report_id, rep_data, length, 1); + if (error = 0) + error = wacom_get_report(intf, WAC_HID_FEATURE_REPORT, + report_id, rep_data, length, 1); } while ((error 0 || rep_data[1] != mode) limit++ WAC_MSG_RETRIES); kfree(rep_data); -- 1.9.0 -- 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/
Re: [PATCH 13/14] device_cgroup: use css_has_online_children() instead of has_children()
On Fri, May 09, 2014 at 05:31:30PM -0400, Tejun Heo wrote:
> devcgroup_update_access() wants to know whether there are child
> cgroups which are online and visible to userland and has_children()
> may return false positive. Replace it with css_has_online_children().
>
> Signed-off-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
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -475,21 +475,6 @@ static int propagate_exception(struct dev_cgroup
> *devcg_root,
> return rc;
> }
>
> -static inline bool has_children(struct dev_cgroup *devcgroup)
> -{
> - bool ret;
> -
> - /*
> - * FIXME: There may be lingering offline csses and this function
> - * may return %true when there isn't any userland-visible child
> - * which is incorrect for our purposes.
> - */
> - rcu_read_lock();
> - ret = css_next_child(NULL, >css);
> - rcu_read_unlock();
> - return ret;
> -}
> -
> /*
> * Modify the exception list using allow/deny rules.
> * CAP_SYS_ADMIN is needed for this. It's at least separate from CAP_MKNOD
> @@ -522,7 +507,7 @@ static int devcgroup_update_access(struct dev_cgroup
> *devcgroup,
> case 'a':
> switch (filetype) {
> case DEVCG_ALLOW:
> - if (has_children(devcgroup))
> + if (css_has_online_children(>css))
> return -EINVAL;
>
> if (!may_allow_all(parent))
> @@ -538,7 +523,7 @@ static int devcgroup_update_access(struct dev_cgroup
> *devcgroup,
> return rc;
> break;
> case DEVCG_DENY:
> - if (has_children(devcgroup))
> + if (css_has_online_children(>css))
> return -EINVAL;
>
> dev_exception_clean(devcgroup);
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/
Re: [PATCH 04/14] device_cgroup: remove direct access to cgroup->children
On Fri, May 09, 2014 at 05:31:21PM -0400, Tejun Heo wrote:
> Currently, devcg::has_children() directly tests cgroup->children for
> list emptiness. The field is not a published field and scheduled to
> go away. In addition, the test isn't strictly correct as devcg should
> 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 Hallyn
> ---
> security/device_cgroup.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 3116015..75b4b18 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -477,9 +477,17 @@ static int propagate_exception(struct dev_cgroup
> *devcg_root,
>
> static inline bool has_children(struct dev_cgroup *devcgroup)
> {
> - struct cgroup *cgrp = devcgroup->css.cgroup;
> + bool ret;
>
> - return !list_empty(>children);
> + /*
> + * FIXME: There may be lingering offline csses and this function
> + * may return %true when there isn't any userland-visible child
> + * which is incorrect for our purposes.
> + */
> + rcu_read_lock();
> + ret = css_next_child(NULL, >css);
> + rcu_read_unlock();
> + return ret;
> }
>
> /*
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/
Re: [PATCH 04/14] device_cgroup: remove direct access to cgroup-children
On Fri, May 09, 2014 at 05:31:21PM -0400, Tejun Heo wrote:
Currently, devcg::has_children() directly tests cgroup-children for
list emptiness. The field is not a published field and scheduled to
go away. In addition, the test isn't strictly correct as devcg should
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 t...@kernel.org
Cc: Aristeu Rozanski a...@redhat.com
Cc: Serge Hallyn serge.hal...@ubuntu.com
---
security/device_cgroup.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 3116015..75b4b18 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -477,9 +477,17 @@ static int propagate_exception(struct dev_cgroup
*devcg_root,
static inline bool has_children(struct dev_cgroup *devcgroup)
{
- struct cgroup *cgrp = devcgroup-css.cgroup;
+ bool ret;
- return !list_empty(cgrp-children);
+ /*
+ * FIXME: There may be lingering offline csses and this function
+ * may return %true when there isn't any userland-visible child
+ * which is incorrect for our purposes.
+ */
+ rcu_read_lock();
+ ret = css_next_child(NULL, devcgroup-css);
+ rcu_read_unlock();
+ return ret;
}
/*
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
Re: [PATCH 13/14] device_cgroup: use css_has_online_children() instead of has_children()
On Fri, May 09, 2014 at 05:31:30PM -0400, Tejun Heo wrote:
devcgroup_update_access() wants to know whether there are child
cgroups which are online and visible to userland and has_children()
may return false positive. Replace it with css_has_online_children().
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Aristeu Rozanski a...@redhat.com
Cc: Serge Hallyn serge.hal...@ubuntu.com
---
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
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -475,21 +475,6 @@ static int propagate_exception(struct dev_cgroup
*devcg_root,
return rc;
}
-static inline bool has_children(struct dev_cgroup *devcgroup)
-{
- bool ret;
-
- /*
- * FIXME: There may be lingering offline csses and this function
- * may return %true when there isn't any userland-visible child
- * which is incorrect for our purposes.
- */
- rcu_read_lock();
- ret = css_next_child(NULL, devcgroup-css);
- rcu_read_unlock();
- return ret;
-}
-
/*
* Modify the exception list using allow/deny rules.
* CAP_SYS_ADMIN is needed for this. It's at least separate from CAP_MKNOD
@@ -522,7 +507,7 @@ static int devcgroup_update_access(struct dev_cgroup
*devcgroup,
case 'a':
switch (filetype) {
case DEVCG_ALLOW:
- if (has_children(devcgroup))
+ if (css_has_online_children(devcgroup-css))
return -EINVAL;
if (!may_allow_all(parent))
@@ -538,7 +523,7 @@ static int devcgroup_update_access(struct dev_cgroup
*devcgroup,
return rc;
break;
case DEVCG_DENY:
- if (has_children(devcgroup))
+ if (css_has_online_children(devcgroup-css))
return -EINVAL;
dev_exception_clean(devcgroup);
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
Re: [PATCH 2/5] cgroup: replace cftype->write_string() with cftype->write()
On Tue, May 06, 2014 at 08:44:23AM -0400, Tejun Heo wrote:
> Convert all cftype->write_string() users to the new cftype->write()
> which maps directly to kernfs write operation and has full access to
> kernfs and cgroup contexts. The conversions are mostly mechanical.
>
> * @css and @cft are accessed using of_css() and of_cft() accessors
> respectively instead of being specified as arguments.
>
> * Should return @nbytes on success instead of 0.
>
> * @buf is not trimmed automatically. Trim if necessary. Note that
> blkcg doesn't need this as blkg_conf_prep() can already handle
> whitespaces.
>
> cftype->write_string() has no user left after the conversions and
> removed.
>
> While at it, remove unnecessary local variable @p in
> cgroup_subtree_control_write() and stale comment about
> CGROUP_LOCAL_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
> ---
> block/blk-throttle.c | 32
> block/cfq-iosched.c | 28 ++--
> include/linux/cgroup.h| 10 +-
> kernel/cgroup.c | 38 +++---
> kernel/cgroup_freezer.c | 20 +---
> kernel/cpuset.c | 16 +---
> mm/hugetlb_cgroup.c | 17 +
> mm/memcontrol.c | 46 +-
> net/ipv4/tcp_memcontrol.c | 16 +---
> security/device_cgroup.c | 14 +++---
> 10 files changed, 118 insertions(+), 119 deletions(-)
(...)
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 8365909..82d6b4f 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -651,27 +651,27 @@ static int devcgroup_update_access(struct dev_cgroup
> *devcgroup,
> return rc;
> }
>
> -static int devcgroup_access_write(struct cgroup_subsys_state *css,
> - struct cftype *cft, char *buffer)
> +static ssize_t devcgroup_access_write(struct kernfs_open_file *of,
> + char *buf, size_t nbytes, loff_t off)
> {
> int retval;
>
> mutex_lock(_mutex);
> - retval = devcgroup_update_access(css_to_devcgroup(css),
> - cft->private, buffer);
> + retval = devcgroup_update_access(css_to_devcgroup(of_css(of)),
> + of_cft(of)->private, strstrip(buf));
> mutex_unlock(_mutex);
> - return retval;
> + return retval ?: nbytes;
> }
>
> static struct cftype dev_cgroup_files[] = {
> {
> .name = "allow",
> - .write_string = devcgroup_access_write,
> + .write = devcgroup_access_write,
> .private = DEVCG_ALLOW,
> },
> {
> .name = "deny",
> - .write_string = devcgroup_access_write,
> + .write = devcgroup_access_write,
> .private = DEVCG_DENY,
> },
> {
for the device_cgroup part
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/
Re: [PATCH 2/5] cgroup: replace cftype-write_string() with cftype-write()
On Tue, May 06, 2014 at 08:44:23AM -0400, Tejun Heo wrote:
Convert all cftype-write_string() users to the new cftype-write()
which maps directly to kernfs write operation and has full access to
kernfs and cgroup contexts. The conversions are mostly mechanical.
* @css and @cft are accessed using of_css() and of_cft() accessors
respectively instead of being specified as arguments.
* Should return @nbytes on success instead of 0.
* @buf is not trimmed automatically. Trim if necessary. Note that
blkcg doesn't need this as blkg_conf_prep() can already handle
whitespaces.
cftype-write_string() has no user left after the conversions and
removed.
While at it, remove unnecessary local variable @p in
cgroup_subtree_control_write() and stale comment about
CGROUP_LOCAL_BUFFER_SIZE in cgroup_freezer.c.
This patch doesn't introduce any visible behavior changes.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Vivek Goyal vgo...@redhat.com
Cc: Jens Axboe ax...@kernel.dk
Cc: Li Zefan lize...@huawei.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Aristeu Rozanski aroza...@redhat.com
---
block/blk-throttle.c | 32
block/cfq-iosched.c | 28 ++--
include/linux/cgroup.h| 10 +-
kernel/cgroup.c | 38 +++---
kernel/cgroup_freezer.c | 20 +---
kernel/cpuset.c | 16 +---
mm/hugetlb_cgroup.c | 17 +
mm/memcontrol.c | 46 +-
net/ipv4/tcp_memcontrol.c | 16 +---
security/device_cgroup.c | 14 +++---
10 files changed, 118 insertions(+), 119 deletions(-)
(...)
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 8365909..82d6b4f 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -651,27 +651,27 @@ static int devcgroup_update_access(struct dev_cgroup
*devcgroup,
return rc;
}
-static int devcgroup_access_write(struct cgroup_subsys_state *css,
- struct cftype *cft, char *buffer)
+static ssize_t devcgroup_access_write(struct kernfs_open_file *of,
+ char *buf, size_t nbytes, loff_t off)
{
int retval;
mutex_lock(devcgroup_mutex);
- retval = devcgroup_update_access(css_to_devcgroup(css),
- cft-private, buffer);
+ retval = devcgroup_update_access(css_to_devcgroup(of_css(of)),
+ of_cft(of)-private, strstrip(buf));
mutex_unlock(devcgroup_mutex);
- return retval;
+ return retval ?: nbytes;
}
static struct cftype dev_cgroup_files[] = {
{
.name = allow,
- .write_string = devcgroup_access_write,
+ .write = devcgroup_access_write,
.private = DEVCG_ALLOW,
},
{
.name = deny,
- .write_string = devcgroup_access_write,
+ .write = devcgroup_access_write,
.private = DEVCG_DENY,
},
{
for the device_cgroup part
Acked-by: Aristeu Rozanski a...@redhat.com
--
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/
Re: [PATCH 3/3] ie31200_edac: Add driver
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 quickly looking at the driver (sorry Jason, no proper review yet :( ) it's a very different beast. Tony, any insights on why? -- 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/
Re: [PATCH 3/3] ie31200_edac: Add driver
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 quickly looking at the driver (sorry Jason, no proper review yet :( ) it's a very different beast. Tony, any insights on why? -- 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/
Re: [PATCH] sb_edac: degrade log level for "EDAC sbridge: Seeking for: dev 1d.3 PCI ID xxxx"
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. > > Signed-off-by: Jiang Liu > --- > drivers/edac/sb_edac.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c > index 54e2abe..347c7a1 100644 > --- a/drivers/edac/sb_edac.c > +++ b/drivers/edac/sb_edac.c > @@ -1263,7 +1263,7 @@ static int sbridge_get_onedevice(struct pci_dev **prev, > struct pci_dev *pdev = NULL; > u8 bus = 0; > > - sbridge_printk(KERN_INFO, > + sbridge_printk(KERN_DEBUG, > "Seeking for: dev %02x.%d PCI ID %04x:%04x\n", > dev_descr->dev, dev_descr->func, > PCI_VENDOR_ID_INTEL, dev_descr->dev_id); ACK -- 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/
Re: [PATCH] sb_edac: degrade log level for EDAC sbridge: Seeking for: dev 1d.3 PCI ID xxxx
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. Signed-off-by: Jiang Liu jiang@linux.intel.com --- drivers/edac/sb_edac.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c index 54e2abe..347c7a1 100644 --- a/drivers/edac/sb_edac.c +++ b/drivers/edac/sb_edac.c @@ -1263,7 +1263,7 @@ static int sbridge_get_onedevice(struct pci_dev **prev, struct pci_dev *pdev = NULL; u8 bus = 0; - sbridge_printk(KERN_INFO, + sbridge_printk(KERN_DEBUG, Seeking for: dev %02x.%d PCI ID %04x:%04x\n, dev_descr-dev, dev_descr-func, PCI_VENDOR_ID_INTEL, dev_descr-dev_id); ACK -- 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/
Re: [PATCH 3/6] cgroup: clean up cgroup_subsys names and initialization
> --- 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(task, devices_subsys_id));
> + return css_to_devcgroup(task_css(task, devices_cgrp_id));
> }
>
> -struct cgroup_subsys devices_subsys;
> -
> /*
> * called under devcgroup_mutex
> */
> @@ -684,13 +682,11 @@ static struct cftype dev_cgroup_files[] = {
> { } /* terminate */
> };
>
> -struct cgroup_subsys devices_subsys = {
> - .name = "devices",
> +struct cgroup_subsys devices_cgrp_subsys = {
> .css_alloc = devcgroup_css_alloc,
> .css_free = devcgroup_css_free,
> .css_online = devcgroup_online,
> .css_offline = devcgroup_offline,
> - .subsys_id = devices_subsys_id,
> .base_cftypes = dev_cgroup_files,
> };
ACK
--
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/
Re: [PATCH 3/6] cgroup: clean up cgroup_subsys names and initialization
--- 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(task, devices_subsys_id));
+ return css_to_devcgroup(task_css(task, devices_cgrp_id));
}
-struct cgroup_subsys devices_subsys;
-
/*
* called under devcgroup_mutex
*/
@@ -684,13 +682,11 @@ static struct cftype dev_cgroup_files[] = {
{ } /* terminate */
};
-struct cgroup_subsys devices_subsys = {
- .name = devices,
+struct cgroup_subsys devices_cgrp_subsys = {
.css_alloc = devcgroup_css_alloc,
.css_free = devcgroup_css_free,
.css_online = devcgroup_online,
.css_offline = devcgroup_offline,
- .subsys_id = devices_subsys_id,
.base_cftypes = dev_cgroup_files,
};
ACK
--
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/
Re: [PATCH 01/12] sb_edac: move PCI IDs to pci_ids.h
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 Rozanski wrote: > >> > 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/drivers/edac/sb_edac.c > >> > index e04462b..4cdd948 100644 > >> > --- a/drivers/edac/sb_edac.c > >> > +++ b/drivers/edac/sb_edac.c > >> > @@ -57,26 +57,9 @@ static int probed; > >> > */ > >> > > >> > /* > >> > - * FIXME: For now, let's order by device function, as it makes > >> > - * easier for driver's development process. This table should be > >> > - * moved to pci_id.h when submitted upstream > >> > >> Why, is anything else besides sb_edac.c using those? > >> > > I think that this patch makes sense, as the other Sandy Bridge registers > > are at pci_ids.h. So, it is a matter of consistency. > > > > Also, I won't doubt that other drivers could need to access those, as > > there are other things there on a few of those PCI IDs. > > > > Yet, on patch 12/12, you're adding the Ivy Bridge specific PCI IDs > > inside the driver. > > > > So, IMHO, you should either move all to pci_ids.h or to keep them inside > > the driver. > > > > My personal taste would be to move them all to pci_ids.h. > > As long as it follows the guideline at the top of pci_ids.h (add them > there only if they are shared between multiple drivers), I'm fine with > putting them in pci_ids.h. Fair enough, I think we can drop the first patch. I checked and all the patches apply without the first one and it builds fine. Mauro, want me to resubmit the patchset anyway? -- 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/
