Re: [PATCH] tpm, tpm_crb: fix le64_to_cpu conversions in crb_acpi_add()
On Tue, Jun 09, 2015 at 10:22:40AM -0600, Jason Gunthorpe wrote: > On Tue, Jun 09, 2015 at 02:36:49PM +0300, Jarkko Sakkinen wrote: > > Needs a commit message, bug description, Fixes: header and does it go > to -stable ? > > > Reported-by: Matt Fleming > > Signed-off-by: Jarkko Sakkinen > > drivers/char/tpm/tpm_crb.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > Obviously there is a problem here with the double swap. But that > should be a nop on x86 hardware, I didn't think there was a BE arch > using ACPI?? No but I don't want to write CRB driver assuming that CRB will be only used on LE platform like x86 even though current HW implementations are only on x86. > Reviewed-By: Jason Gunthorpe > > Jason /Jarkko -- 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 V2] checkpatch: Add some _destroy functions to NEEDLESS_IF tests
Sergey Senozhatsky has modified several destroy functions that can
now be called with NULL values.
- kmem_cache_destroy()
- mempool_destroy()
- dma_pool_destroy()
Update checkpatch to warn when those functions are preceded by an if.
Update checkpatch to --fix all the calls too only when the code style
form is using leading tabs.
from:
if (foo)
(foo);
to:
(foo);
Signed-off-by: Joe Perches
---
V2: Remove useless debugging print messages and multiple quotemetas
scripts/checkpatch.pl | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 69c4716..87d3bf1aa 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4800,10 +4800,34 @@ sub process {
# check for needless "if () fn()" uses
if ($prevline =~ /\bif\s*\(\s*($Lval)\s*\)/) {
- my $expr = '\s*\(\s*' . quotemeta($1) . '\s*\)\s*;';
- if ($line =~
/\b(kfree|usb_free_urb|debugfs_remove(?:_recursive)?)$expr/) {
- WARN('NEEDLESS_IF',
-"$1(NULL) is safe and this check is
probably not required\n" . $hereprev);
+ my $tested = quotemeta($1);
+ my $expr = '\s*\(\s*' . $tested . '\s*\)\s*;';
+ if ($line =~
/\b(kfree|usb_free_urb|debugfs_remove(?:_recursive)?|(?:kmem_cache|mempool|dma_pool)_destroy)$expr/)
{
+ my $func = $1;
+ if (WARN('NEEDLESS_IF',
+"$func(NULL) is safe and this check is
probably not required\n" . $hereprev) &&
+ $fix) {
+ my $do_fix = 1;
+ my $leading_tabs = "";
+ my $new_leading_tabs = "";
+ if ($lines[$linenr - 2] =~
/^\+(\t*)if\s*\(\s*$tested\s*\)\s*$/) {
+ $leading_tabs = $1;
+ } else {
+ $do_fix = 0;
+ }
+ if ($lines[$linenr - 1] =~
/^\+(\t+)$func\s*\(\s*$tested\s*\)\s*;\s*$/) {
+ $new_leading_tabs = $1;
+ if (length($leading_tabs) + 1
ne length($new_leading_tabs)) {
+ $do_fix = 0;
+ }
+ } else {
+ $do_fix = 0;
+ }
+ if ($do_fix) {
+ fix_delete_line($fixlinenr - 1,
$prevrawline);
+ $fixed[$fixlinenr] =~
s/^\+$new_leading_tabs/\+$leading_tabs/;
+ }
+ }
}
}
--
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] regulator: core: fix constraints output buffer
> Mark Brown hat am 10. Juni 2015 um 01:22 geschrieben: > > > On Tue, Jun 09, 2015 at 08:09:42PM +, Stefan Wahren wrote: > > The buffer for condtraints debug isn't big enough to hold the output > > in all cases. So fix this issue by increasing the buffer. > > Applied, thanks. Will you send a rebased version of the scnprintf() > patch as well? Why certainly! -- 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: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions
> > Well I like it, even though it's going to cause a zillion little cleanup
> > patches.
Actually only at most 87. There are some functions that look quite a bit
nicer with the change, like:
void jffs2_destroy_slab_caches(void)
{
- if(full_dnode_slab)
- kmem_cache_destroy(full_dnode_slab);
- if(raw_dirent_slab)
- kmem_cache_destroy(raw_dirent_slab);
- if(raw_inode_slab)
- kmem_cache_destroy(raw_inode_slab);
- if(tmp_dnode_info_slab)
- kmem_cache_destroy(tmp_dnode_info_slab);
- if(raw_node_ref_slab)
- kmem_cache_destroy(raw_node_ref_slab);
- if(node_frag_slab)
- kmem_cache_destroy(node_frag_slab);
- if(inode_cache_slab)
- kmem_cache_destroy(inode_cache_slab);
+ kmem_cache_destroy(full_dnode_slab);
+ kmem_cache_destroy(raw_dirent_slab);
+ kmem_cache_destroy(raw_inode_slab);
+ kmem_cache_destroy(tmp_dnode_info_slab);
+ kmem_cache_destroy(raw_node_ref_slab);
+ kmem_cache_destroy(node_frag_slab);
+ kmem_cache_destroy(inode_cache_slab);
#ifdef CONFIG_JFFS2_FS_XATTR
- if (xattr_datum_cache)
- kmem_cache_destroy(xattr_datum_cache);
- if (xattr_ref_cache)
- kmem_cache_destroy(xattr_ref_cache);
+ kmem_cache_destroy(xattr_datum_cache);
+ kmem_cache_destroy(xattr_ref_cache);
#endif
}
I can try to check and submit the patches.
julia
--
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 v5 1/2] watchdog_core: Add watchdog registration deferral mechanism
On 06/09/2015 09:55 AM, Jean-Baptiste Theou wrote: Currently, watchdog subsystem require the misc subsystem to register a watchdog. This may not be the case in case of an early registration of a watchdog, which can be required when the watchdog cannot be disabled. This patch introduces a deferral mechanism to remove this requirement. Signed-off-by: Jean-Baptiste Theou --- Now you have a couple of unnecessary continuation lines ;-) Anyway, I think this is good enough. Reviewed-by: Guenter Roeck Thanks, Guenter -- 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 v5 2/2] gpio_wdt: Add option for early registration
On 06/09/2015 09:55 AM, Jean-Baptiste Theou wrote: In some situation, mainly when it's not possible to disable a watchdog, you may want the watchdog driver to be started as soon as possible. Adding GPIO_WATCHDOG_ARCH_INITCALL to raise initcall from module_init to arch_initcall. This patch require watchdog registration deferral mechanism Signed-off-by: Jean-Baptiste Theou --- Reviewed-by: Guenter Roeck Thanks, Guenter -- 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] atm: idt77105: Use setup_timer
Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@change@
expression e1, e2, a;
@@
-init_timer();
+setup_timer(, a, 0UL);
... when != a = e2
-e1.function = a;
Signed-off-by: Vaishali Thakkar
---
drivers/atm/idt77105.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/atm/idt77105.c b/drivers/atm/idt77105.c
index 909c95b..feb023d 100644
--- a/drivers/atm/idt77105.c
+++ b/drivers/atm/idt77105.c
@@ -306,14 +306,12 @@ static int idt77105_start(struct atm_dev *dev)
if (start_timer) {
start_timer = 0;
- init_timer(_timer);
+ setup_timer(_timer, idt77105_stats_timer_func, 0UL);
stats_timer.expires = jiffies+IDT77105_STATS_TIMER_PERIOD;
- stats_timer.function = idt77105_stats_timer_func;
add_timer(_timer);
- init_timer(_timer);
+ setup_timer(_timer, idt77105_restart_timer_func, 0UL);
restart_timer.expires = jiffies+IDT77105_RESTART_TIMER_PERIOD;
- restart_timer.function = idt77105_restart_timer_func;
add_timer(_timer);
}
spin_unlock_irqrestore(_priv_lock, flags);
--
1.9.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 2/2] scatterlist: cleanup sg_chain() and sg_unmark_end()
On Tue, Jun 09, 2015 at 12:27:15PM -0400, Dan Williams wrote: > > +#define scatterwalk_sg_chain(prv, num, sgl) sg_chain(prv, num, sgl) > +#define scatterwalk_sg_next(sgl) sg_next(sgl) Why are you reintroducing the scatterwalk_sg_next macro that we just removed? I also don't understand why this is so urgent that it has to go into mainline at this late date. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/
ftrace question
Hi, I apologize for the wide audience but I did not get response. How to see the args passed to for example trace_ocfs2_dentry_attach_loc() using /sys/kernel/debug/tracing. I can only see function names and parent fn ls-4530 [000] 10532818.195802: ocfs2_dentry_attach_lock <-ocfs2_lookup It seems as though a separate formatter is used to print these when traced with raw options or something like that. Thanks -Tariq Saeed -- 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: [RFC PATCH] usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes
Hi, On Tuesday 09 June 2015 10:54 PM, Alan Stern wrote: On Tue, 9 Jun 2015, Kishon Vijay Abraham I wrote: But with a bounce buffer that's only 512 bytes long, you can never send an entire packet's worth of data. If the bounce buffer is 1024 bytes for control endpoint, 512 bytes should be sufficient to send entire packet right? Yes, you're right. I had confused control endpoints with bulk endpoints, where the maxpacket size is 1024. Sorry for the mistake. no problem. then you can send the entire first packet. When that's done, you can send the second packet. And so on. It wouldn't be quite as fast, but for ep0 that shouldn't matter. right! this is a variant of what I tried to implement in chained TRB [1]. $subject tries just to avoid memory corruption instead of actually trying to receive all the data. Okay. If you take the $SUBJECT approach, I think it would be better for an URB submission to fail than for the host controller to send only part of the data. Could be but we also want to prevent mem corruption in the case of a faulty host to be more robust. Thanks Kishon -- 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: [PATCHv2] ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
On 09.06.2015 13:07, Anand Moon wrote: > Enable CONFIG_SND_SOC_ODROIDX2 and CONFIG_SND_SIMPLE_CARD to enable > sound on Odroid-XU3 board using the max98090 audio codec. > > Signed-off-by: Anand Moon > Reviewed-by: Lukasz Majewski > --- > Changes v2: Fixed the commit log. > > Signed-off-by: Anand Moon Thanks, applied. I'll send later to Kukjin for 4.3. Unless he picks it also, in that case: Acked-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 000/178] 3.18.15-review
On Tue, Jun 09, 2015 at 10:17:11AM -0700, Kevin Hilman wrote: > Hi Sasha, > > On Mon, Jun 8, 2015 at 6:39 AM, Sasha Levin wrote: > > This is the start of the stable review cycle for the 3.18.15 release. > > There are 178 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > We've started build/boot testing your 3.18 stable queue with the > automated build/boot tools at the kernelci.org project. We'll soon be > sending automated reports to this list for your stable queue (and > other stable trees.) Until we have the email reports automated, below > is the report for this review series which has a whole pile of build > failures across x86, arm and arm64. > > Kevin > > > > stable-sasha build: 143 builds: 136 failed, 7 passed, 374 errors, 284 > warnings (v3.18.14-178-gaf1f9d92cb53) > Somehow I completely missed that announcement. Build results: total: 123 pass: 7 fail: 116 Failed builds: alpha:defconfig alpha:allmodconfig arc:defconfig arm:allmodconfig arm:s3c2410_defconfig arm:omap2plus_defconfig arm:imx_v6_v7_defconfig arm:ixp4xx_defconfig arm:u8500_defconfig arm:multi_v5_defconfig arm:multi_v7_defconfig arm:omap1_defconfig arm:footbridge_defconfig arm:davinci_all_defconfig arm:mini2440_defconfig arm:rpc_defconfig arm:axm55xx_defconfig arm:mxs_defconfig arm:keystone_defconfig arm:vexpress_defconfig arm:imx_v4_v5_defconfig arm:at91_dt_defconfig arm:s3c6400_defconfig arm:lpc32xx_defconfig arm:shmobile_defconfig arm:nhk8815_defconfig arm:bcm2835_defconfig arm:sama5_defconfig arm:orion5x_defconfig arm:exynos_defconfig arm:cm_x2xx_defconfig arm:s5pv210_defconfig arm:integrator_defconfig arm:efm32_defconfig arm:pxa910_defconfig arm:clps711x_defconfig arm64:defconfig arm64:allmodconfig avr32:defconfig avr32:merisc_defconfig avr32:atngw100mkii_evklcd101_defconfig blackfin:defconfig blackfin:BF561-EZKIT-SMP_defconfig c6x:dsk6455_defconfig c6x:evmc6457_defconfig c6x:evmc6678_defconfig cris:defconfig cris:etrax-100lx_defconfig cris:artpec_3_defconfig cris:etraxfs_defconfig frv:defconfig hexagon:defconfig i386:defconfig i386:allyesconfig i386:allmodconfig ia64:defconfig m32r:defconfig m68k:defconfig m68k:allmodconfig m68k:sun3_defconfig m68k:m5272c3_defconfig m68k:m5307c3_defconfig m68k:m5249evb_defconfig m68k:m5407c3_defconfig m68k:m5475evb_defconfig metag:defconfig metag:meta1_defconfig metag:meta2_defconfig metag:meta2_smp_defconfig microblaze:mmu_defconfig microblaze:nommu_defconfig mips:defconfig mips:allmodconfig mips:bcm47xx_defconfig mips:bcm63xx_defconfig mips:nlm_xlp_defconfig mips:ath79_defconfig mips:ar7_defconfig mips:fuloong2e_defconfig mips:e55_defconfig mips:cavium_octeon_defconfig mips:malta_defconfig parisc:defconfig parisc:generic-32bit_defconfig parisc:a500_defconfig parisc:generic-64bit_defconfig powerpc:defconfig powerpc:allmodconfig powerpc:ppc64e_defconfig powerpc:cell_defconfig powerpc:maple_defconfig powerpc:ppc6xx_defconfig powerpc:mpc83xx_defconfig powerpc:mpc85xx_defconfig powerpc:mpc85xx_smp_defconfig powerpc:tqm8xx_defconfig powerpc:85xx/sbc8548_defconfig powerpc:83xx/mpc834x_mds_defconfig powerpc:86xx/sbc8641d_defconfig s390:defconfig s390:allmodconfig score:defconfig sh:defconfig sh:dreamcast_defconfig sh:microdev_defconfig sparc32:defconfig sparc64:defconfig sparc64:allmodconfig tile:tilegx_defconfig um:defconfig unicore32:defconfig x86_64:defconfig x86_64:allyesconfig x86_64:allmodconfig xtensa:defconfig xtensa:allmodconfig Qemu test results: total: 30 pass: 1 fail: 29 Failed tests: alpha:alpha_defconfig arm:arm_versatile_defconfig arm:arm_vexpress_defconfig arm64:arm64_smp_defconfig arm64:arm64_nosmp_defconfig metag:metag_defconfig microblaze:microblaze_defconfig microblaze:microblazeel_defconfig mips:mips_malta_defconfig mips:mips_malta_smp_defconfig mips:mipsel_malta_defconfig mips:mipsel_malta_smp_defconfig mips64:mips_malta64_defconfig
Re: A race condition between debugfs and seq_file operation
On Wed, Jun 10, 2015 at 05:00:03AM +, Lisa Du wrote:
> > -Original Message-
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > Sent: 2015年6月10日 5:12
> > To: Lisa Du
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: A race condition between debugfs and seq_file operation
> >
> > On Mon, Jun 08, 2015 at 04:28:10AM +, Lisa Du wrote:
> > > Hi, All
> > > Recently I met one race condition related to debugfs.
> > >
> > > Take an example from ion.c in kernel3.14:
> > > static int ion_debug_client_open(struct inode *inode, struct file
> > > *file) {
> > > return single_open(file, ion_debug_client_show, inode->i_private); }
> > >
> > > static const struct file_operations debug_client_fops = {
> > > .open = ion_debug_client_open,
> > > .read = seq_read,
> > > .llseek = seq_lseek,
> > > .release = single_release,
> > > };
> > > client->debug_root = debugfs_create_file(client->display_name, 0664,
> > > dev->clients_debug_root,
> > > client, _client_fops);
> > >
> > > I find during I read the debugfs node, driver can do
> > > debugfs_remove_recursive(dentry); Is it expected?
> >
> > Yes. Well, not "expected", but a mess, yes.
> >
> > Removing debugfs files are known to have lots of races, this isn't the only
> > one :(
> Thanks for the reply!
> Not sure if there is any plan to resolve such races in the future?
Yes, I have "plans", but it's on my very long todo list behind lots of
other things...
If you want to look into it, please, that would be wonderful.
thanks,
greg k-h
--
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 RFC] net: phy: Introduced the PHY_AN_PENDING state
Le 06/09/15 21:36, Keng Soon Cheah a écrit :
> The PHY_AN_PENDING state is put as a gate to enter the PHY_AN state
> where it will wait for any uncomplete auto-negotiation session to
> finish before starting a new one.
>
> This extra state could be used to workaround some auto-negotation
> issues from certain vendors.
The typical way to work around these problems are to fix them at the PHY
driver level, see below.
>
> an_pending_timeout module parameter is used to enable the AN_PENDING
> transition state. Set it to 0 to disable AN_PENDING state transition,
> set it to any non-zero value to specify the timeout period for
> PHY_AN_PENDING state in second. The default value is 0.
>
> an_pending_guard module parameter serves as a guard band to delay
> the auto-negotiation firing after the previous auto-negotiation
> finish.
>
> Signed-off-by: Keng Soon Cheah
>
> Conflicts:
>
> drivers/net/phy/phy.c
> ---
> We observed failure in the ethernet link operation when our board pairs
> with some network switch model. The problem happens when an
> auto-negotiation is started around the time the previous auto-negotiation
> complete. We believe this might be an interoperatibility issue between
> the PHYs but we need a short-term solution in software to workaround the
> issue.
>
> We found that we are able to avoid from hitting the problem by waiting any
> pending auto-negotiation to complete before starting a new one and this
> patch is designed to serve the purpose.
That sounds like a bug in the PHY state machine and/or the PHY driver if
you are allowed to restart auto-negotiation while one is pending. Now
that the PHY state machine has debug prints built-in, could you capture
a trace of this failing case?
Is this observed with the generic PHY driver or a custom PHY driver?
>
> A PHY_AN_PENDING state is introduced and it will act as a gate to enter
> the PHY_AN state. This state will check for auto-negotiation completion
> or timeout after an_pending_timeout period, then it will wait for
> an_pending_guard before triggering another auto-negotiation.
>
> The following diagram shows the timing diagram
>
>
>an_pending_timeout an_pending_guard
>V V auto-nego
>|->||
> ^
>auto-negotiation complete/timeout
>
> We do not have plan to submit this patch upstream (unless the community
> feels this patch is useful in general) but we would like to seek for
> feedback or advice if this patch could introduce new problems.
As usual with state machines, introducing a new state needs to be
carefully done in order to make sure that all transitions are correct,
so far I would rather work on finding the root cause/extending the
timeout and/or making it configurable on a PHY-driver basis rather than
having this additional state which is more error prone.
Thanks!
>
> ---
> drivers/net/phy/phy.c | 44 +++-
> include/linux/phy.h |3 ++-
> 2 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index b2197b5..35e6484 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -38,6 +38,16 @@
>
> #include
>
> +static unsigned int an_pending_timeout;
> +module_param(an_pending_timeout, uint, 0644);
> +MODULE_PARM_DESC(an_pending_timeout,
> + "Timeout period for PHY_AN_PENDING state in second. 0 to disable
> PHY_AN_PENDING state (default)");
> +
> +static unsigned int an_pending_guard;
> +module_param(an_pending_guard, uint, 0644);
> +MODULE_PARM_DESC(an_pending_guard,
> + "Guard band period before firing auto-negotiation from PHY_AN_PENDING
> state in second. Default to 0");
> +
> static const char *phy_speed_to_str(int speed)
> {
> switch (speed) {
> @@ -82,7 +92,6 @@ static const char *phy_state_to_str(enum phy_state st)
> return NULL;
> }
>
> -
> /**
> * phy_print_status - Convenience function to print out the current phy
> status
> * @phydev: the phy_device struct
> @@ -485,6 +494,18 @@ int phy_start_aneg(struct phy_device *phydev)
>
> /* Invalidate LP advertising flags */
> phydev->lp_advertising = 0;
> + if (an_pending_timeout) {
> + switch (phydev->state) {
> + case PHY_AN_PENDING:
> + case PHY_HALTED:
> + break;
> + default:
> + phydev->state = PHY_AN_PENDING;
> + phydev->link_timeout = an_pending_timeout;
> + goto out_unlock;
> + }
> +
> + }
>
> err = phydev->drv->config_aneg(phydev);
> if (err < 0)
> @@ -831,6 +852,27 @@ void phy_state_machine(struct work_struct *work)
> phydev->link_timeout = PHY_AN_TIMEOUT;
>
> break;
> + case PHY_AN_PENDING:
> +
Re: [RFC PATCH] powerpc/numa: initialize distance lookup table from drconf path
Reworded commit log:
From: Nikunj A Dadhania
powerpc/numa: initialize distance lookup table from drconf path
In some situations, a NUMA guest that supports
ibm,dynamic-memory-reconfiguration node will end up having flat NUMA
distances between nodes. This is because of two problems in the
current code.
1) Different representations of associativity lists.
There is an assumption about the associativity list in
initialize_distance_lookup_table(). Associativity list has two forms:
a) [cpu,memory]@x/ibm,associativity has following
format:
b) ibm,dynamic-reconfiguration-memory/ibm,associativity-lookup-arrays
M = the number of associativity lists
N = the number of entries per associativity list
Fix initialize_distance_lookup_table() so that it does not assume
"case a". And update the caller to skip the length field before
sending the associativity list.
2) Distance table not getting updated from drconf path.
Node distance table will not get initialized in certain cases as
ibm,dynamic-reconfiguration-memory path does not initialize the
lookup table.
Call initialize_distance_lookup_table() from drconf path with
appropriate associativity list.
Reported-by: Bharata B Rao
Signed-off-by: Nikunj A Dadhania
---
arch/powerpc/mm/numa.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 5e80621..8b9502a 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -225,7 +225,7 @@ static void initialize_distance_lookup_table(int nid,
for (i = 0; i < distance_ref_points_depth; i++) {
const __be32 *entry;
- entry = [be32_to_cpu(distance_ref_points[i])];
+ entry = [be32_to_cpu(distance_ref_points[i]) - 1];
distance_lookup_table[nid][i] = of_read_number(entry, 1);
}
}
@@ -248,8 +248,12 @@ static int associativity_to_nid(const __be32
*associativity)
nid = -1;
if (nid > 0 &&
- of_read_number(associativity, 1) >= distance_ref_points_depth)
- initialize_distance_lookup_table(nid, associativity);
+ of_read_number(associativity, 1) >= distance_ref_points_depth) {
+ /*
+* Skip the length field and send start of associativity array
+*/
+ initialize_distance_lookup_table(nid, associativity + 1);
+ }
out:
return nid;
@@ -507,6 +511,12 @@ static int of_drconf_to_nid_single(struct of_drconf_cell
*drmem,
if (nid == 0x || nid >= MAX_NUMNODES)
nid = default_nid;
+
+ if (nid > 0) {
+ index = drmem->aa_index * aa->array_sz;
+ initialize_distance_lookup_table(nid,
+ >arrays[index]);
+ }
}
return nid;
--
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: A race condition between debugfs and seq_file operation
> -Original Message-
> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> Sent: 2015年6月10日 5:12
> To: Lisa Du
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: A race condition between debugfs and seq_file operation
>
> On Mon, Jun 08, 2015 at 04:28:10AM +, Lisa Du wrote:
> > Hi, All
> > Recently I met one race condition related to debugfs.
> >
> > Take an example from ion.c in kernel3.14:
> > static int ion_debug_client_open(struct inode *inode, struct file
> > *file) {
> > return single_open(file, ion_debug_client_show, inode->i_private); }
> >
> > static const struct file_operations debug_client_fops = {
> > .open = ion_debug_client_open,
> > .read = seq_read,
> > .llseek = seq_lseek,
> > .release = single_release,
> > };
> > client->debug_root = debugfs_create_file(client->display_name, 0664,
> > dev->clients_debug_root,
> > client, _client_fops);
> >
> > I find during I read the debugfs node, driver can do
> > debugfs_remove_recursive(dentry); Is it expected?
>
> Yes. Well, not "expected", but a mess, yes.
>
> Removing debugfs files are known to have lots of races, this isn't the only
> one :(
Thanks for the reply!
Not sure if there is any plan to resolve such races in the future?
>
> thanks,
>
> greg k-h
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [PATCH] ACPI / init: Switch over platform to the ACPI mode later
On Wed, Jun 10, 2015 at 01:48:29AM +0200, Rafael J. Wysocki wrote: > On Wednesday, June 03, 2015 11:13:57 AM Toshi Kani wrote: > > On Sat, 2015-05-30 at 14:21 +0200, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > > > Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before > > > timekeeping_init()" moved the ACPI subsystem initialization, > > > including the ACPI mode enabling, to an earlier point in the > > > initialization sequence, to allow the timekeeping subsystem > > > use ACPI early. Unfortunately, that resulted in boot regressions > > > on some systems and the early ACPI initialization was moved toward > > > its original position in the kernel initialization code by commit > > > c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later". > > > > > > However, that turns out to be insufficient, as boot is still broken > > > on the Tyan S8812 mainboard. > > > > > > To fix that issue, split the ACPI early initialization code into > > > two pieces so the majority of it still located in acpi_early_init() > > > and the part switching over the platform into the ACPI mode goes into > > > a new function, acpi_subsystem_init(), executed at the original early > > > ACPI initialization spot. > > > > > > That fixes the Tyan S8812 boot problem, but still allows ACPI > > > tables to be loaded earlier which is useful to the EFI code in > > > efi_enter_virtual_mode(). > > > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141 > > > Reported-and-tested-by: Marius Tolzmann > > > Signed-off-by: Rafael J. Wysocki > > > > Can you add comments to acpi_early_init() and acpi_subsystem_init() to > > clarify what ACPI features are enabled at each phase, and what > > dependency they have in the boot sequence? (The same goes to > > early_acpi_boot_init() and acpi_boot_init().) > > OK, update follows. > > --- > From: Rafael J. Wysocki > Subject: ACPI / init: Switch over platform to the ACPI mode later > > Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before > timekeeping_init()" moved the ACPI subsystem initialization, > including the ACPI mode enabling, to an earlier point in the > initialization sequence, to allow the timekeeping subsystem > use ACPI early. Unfortunately, that resulted in boot regressions > on some systems and the early ACPI initialization was moved toward > its original position in the kernel initialization code by commit > c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later". > > However, that turns out to be insufficient, as boot is still broken > on the Tyan S8812 mainboard. > > To fix that issue, split the ACPI early initialization code into > two pieces so the majority of it still located in acpi_early_init() > and the part switching over the platform into the ACPI mode goes into > a new function, acpi_subsystem_init(), executed at the original early > ACPI initialization spot. > > That fixes the Tyan S8812 boot problem, but still allows ACPI > tables to be loaded earlier which is useful to the EFI code in > efi_enter_virtual_mode(). > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141 > Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before > timekeeping_init()" > Reported-and-tested-by: Marius Tolzmann > Signed-off-by: Rafael J. Wysocki > Acked-by: Toshi Kani > --- > drivers/acpi/bus.c | 56 > +-- > include/linux/acpi.h |2 + > init/main.c |1 > 3 files changed, 44 insertions(+), 15 deletions(-) About bko#97141, I am still curious why the platform didn't set SCI_EN in that early stage. Thanks for Rafael's patch. Reviewed-by: Lee, Chun-Yi Regards Joey Lee -- 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 v14 4/4] cgroup: implement the PIDs subsystem
On Tue, Jun 09, 2015 at 09:32:10PM +1000, Aleksa Sarai wrote: > Adds a new single-purpose PIDs subsystem to limit the number of > tasks that can be forked inside a cgroup. Essentially this is an > implementation of RLIMIT_NPROC that applies to a cgroup rather than a > process tree. > > However, it should be noted that organisational operations (adding and > removing tasks from a PIDs hierarchy) will *not* be prevented. Rather, > the number of tasks in the hierarchy cannot exceed the limit through > forking. This is due to the fact that, in the unified hierarchy, attach > cannot fail (and it is not possible for a task to overcome its PIDs > cgroup policy limit by attaching to a child cgroup -- even if migrating > mid-fork it must be able to fork in the parent first). > > PIDs are fundamentally a global resource, and it is possible to reach > PID exhaustion inside a cgroup without hitting any reasonable kmemcg > policy. Once you've hit PID exhaustion, you're only in a marginally > better state than OOM. This subsystem allows PID exhaustion inside a > cgroup to be prevented. Patches 3-4 look good to me. Will apply once v4.3 dev window opens. Thanks. -- tejun -- 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/
[RFC PATCH] powerpc/numa: initialize distance lookup table from drconf path
Node distance will not get initialized in certain cases as
dynamic-reconfiguration path does not initialize the lookup table.
There is an assumption about the associativity list in
initialize_distance_lookup_table(). Associativity list has two forms:
a) [cpu,memory]@x/ibm,associativity has following
format:
b) ibm,dynamic-reconfiguration-memory/ibm,associativity-lookup-arrays
M = the number of associativity lists
N = the number of entries per associativity list
Fix initialize_distance_lookup_table() so that it does not assume
"case a". And update the caller to skip the length field before
sending the associativity list.
Call initialize_distance_lookup_table() from drconf path with
appropriate associativity list.
Reported-by: Bharata B Rao
Signed-off-by: Nikunj A Dadhania
---
arch/powerpc/mm/numa.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 5e80621..8b9502a 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -225,7 +225,7 @@ static void initialize_distance_lookup_table(int nid,
for (i = 0; i < distance_ref_points_depth; i++) {
const __be32 *entry;
- entry = [be32_to_cpu(distance_ref_points[i])];
+ entry = [be32_to_cpu(distance_ref_points[i]) - 1];
distance_lookup_table[nid][i] = of_read_number(entry, 1);
}
}
@@ -248,8 +248,12 @@ static int associativity_to_nid(const __be32
*associativity)
nid = -1;
if (nid > 0 &&
- of_read_number(associativity, 1) >= distance_ref_points_depth)
- initialize_distance_lookup_table(nid, associativity);
+ of_read_number(associativity, 1) >= distance_ref_points_depth) {
+ /*
+* Skip the length field and send start of associativity array
+*/
+ initialize_distance_lookup_table(nid, associativity + 1);
+ }
out:
return nid;
@@ -507,6 +511,12 @@ static int of_drconf_to_nid_single(struct of_drconf_cell
*drmem,
if (nid == 0x || nid >= MAX_NUMNODES)
nid = default_nid;
+
+ if (nid > 0) {
+ index = drmem->aa_index * aa->array_sz;
+ initialize_distance_lookup_table(nid,
+ >arrays[index]);
+ }
}
return nid;
--
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 v14 1/4] cgroup: fix uninitialised iterator in for_each_subsys_which
On Tue, Jun 09, 2015 at 09:32:07PM +1000, Aleksa Sarai wrote:
> Fix the fact that @ssid is uninitialised in the case where
> CGROUP_SUBSYS_COUNT = 0 by setting ssid to 0.
>
> Fixes: cb4a31675270 ("cgroup: use bitmask to filter for_each_subsys")
> Signed-off-by: Aleksa Sarai
Applied to cgroup/for-4.2.
Thanks.
--
tejun
--
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: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions
On Tue, 2015-06-09 at 19:17 -0700, Andrew Morton wrote:
> On Tue, 9 Jun 2015 21:00:58 -0500 (CDT) Christoph Lameter
> wrote:
> > On Tue, 9 Jun 2015, Andrew Morton wrote:
> > > > Why do this at all?
> > Did some grepping and I did see some call sites that do this but the
> > majority has to do other processing as well.
> >
> > 200 call sites? Do we have that many uses of caches? Typical prod system
> > have ~190 caches active and the merging brings that down to half of that.
> I didn't try terribly hard.
> z:/usr/src/linux-4.1-rc7> grep -r -C1 kmem_cache_destroy . | grep "if [(]" |
> wc -l
> 158
>
> It's a lot, anyway.
Yeah.
$ git grep -E -B1 -w "(kmem_cache|mempool|dma_pool)_destroy" *| \
grep -P "\bif\s*\(" | wc -l
268
--
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] libata: finally use __initconst in ata_parse_force_one()
On Tue, Jun 09, 2015 at 03:33:19PM +0200, Rasmus Villemoes wrote: > Just six days after this FIXME was added seven years ago, Sam Ravnborg > added the missing feature (37c514e3dfc8 "Add missing init section > definitions"), though it ended up being called __initconst. > > Let's use it; better late than never. Heh, seriously. Applied to libata/for-4.2. Thanks! -- tejun -- 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 0/2] Fixup lusre ll_getname
From: Oleg Drokin Some time ago Al Viro noticed that lustre ll_getname is broken. At the time a patch was submitted to convert lustre to use exported getname, that was rejected by hch on the grounds that filesystem code sould not really be reimplementing their own lookups which kind of made sense back then. But upon further investigation it seems that ll_getname is used in a different way, it only gets a single path name component that is then shiped to the server for some operations. Going through VFS here to do proper lookups is not really all that good of an idea since dcache pollution is undesired at the very least. So these two patches drop one of the ll_getname users that could be done in another way and fix up ll_getname to only allocate a single pathname component buffer and properly check copy from userspace return value. Please consider. Oleg Drokin (2): staging/lustre/llite: remove LL_IOC_REMOVE_ENTRY handler staging/lustre/llite: fix ll_getname drivers/staging/lustre/lustre/llite/dir.c | 49 +++ 1 file changed, 11 insertions(+), 38 deletions(-) -- 2.1.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/
[PATCH 1/2] staging/lustre/llite: remove LL_IOC_REMOVE_ENTRY handler
From: Oleg Drokin
It uses getname in unsafe manner and since it's to deal with corrupted
or inconsistent filesystem, we are probably better to deal with
it from lfsck anyway.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/llite/dir.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index 4b0de8d..87a042c 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1436,35 +1436,6 @@ free_lmv:
kfree(tmp);
return rc;
}
- case LL_IOC_REMOVE_ENTRY: {
- char*filename = NULL;
- int namelen = 0;
- int rc;
-
- /* Here is a little hack to avoid sending REINT_RMENTRY to
-* unsupported server, which might crash the server(LU-2730),
-* Because both LVB_TYPE and REINT_RMENTRY will be supported
-* on 2.4, we use OBD_CONNECT_LVB_TYPE to detect whether the
-* server will support REINT_RMENTRY XXX*/
- if (!(exp_connect_flags(sbi->ll_md_exp) & OBD_CONNECT_LVB_TYPE))
- return -ENOTSUPP;
-
- filename = ll_getname((const char *)arg);
- if (IS_ERR(filename))
- return PTR_ERR(filename);
-
- namelen = strlen(filename);
- if (namelen < 1) {
- rc = -EINVAL;
- goto out_rmdir;
- }
-
- rc = ll_rmdir_entry(inode, filename, namelen);
-out_rmdir:
- if (filename)
- ll_putname(filename);
- return rc;
- }
case LL_IOC_LOV_SWAP_LAYOUTS:
return -EPERM;
case LL_IOC_OBD_STATFS:
--
2.1.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/
[PATCH 2/2] staging/lustre/llite: fix ll_getname user buffer copy
From: Oleg Drokin
strncpy_from_user could return negative values on error,
so need to take those into account.
Since ll_getname is used to get a single component name from userspace
to transfer to server as-is, there's no need to allocate 4k buffer
as done by __getname. Allocate NAME_MAX+1 buffer instead to ensure
we have enough for a null terminated max valid length buffer.
This was discovered by Al Viro in https://lkml.org/lkml/2015/4/11/243
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/llite/dir.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index 87a042c..e0b9043 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1213,29 +1213,31 @@ out:
return rc;
}
-static char *
-ll_getname(const char __user *filename)
+/* This function tries to get a single name component,
+ * to send to the server. No actual path traversal involved,
+ * so we limit to NAME_MAX */
+static char *ll_getname(const char __user *filename)
{
int ret = 0, len;
- char *tmp = __getname();
+ char *tmp = kzalloc(NAME_MAX + 1, GFP_KERNEL);
if (!tmp)
return ERR_PTR(-ENOMEM);
- len = strncpy_from_user(tmp, filename, PATH_MAX);
- if (len == 0)
+ len = strncpy_from_user(tmp, filename, NAME_MAX);
+ if (len < 0)
+ ret = len;
+ else if (len == 0)
ret = -ENOENT;
- else if (len > PATH_MAX)
- ret = -ENAMETOOLONG;
if (ret) {
- __putname(tmp);
+ kfree(tmp);
tmp = ERR_PTR(ret);
}
return tmp;
}
-#define ll_putname(filename) __putname(filename)
+#define ll_putname(filename) kfree(filename)
static long ll_dir_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
{
--
2.1.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/
[PATCH] checkpatch: Add some _destroy functions to NEEDLESS_IF tests
Sergey Senozhatsky has modified several destroy functions that can
now be called with NULL values.
- kmem_cache_destroy()
- mempool_destroy()
- dma_pool_destroy()
Update checkpatch to warn when those functions are preceded by an if.
Update checkpatch to --fix all the calls too only when the code style
form is using leading tabs.
from:
if (foo)
(foo);
to:
(foo);
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 69c4716..2eff013 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4800,10 +4800,37 @@ sub process {
# check for needless "if () fn()" uses
if ($prevline =~ /\bif\s*\(\s*($Lval)\s*\)/) {
- my $expr = '\s*\(\s*' . quotemeta($1) . '\s*\)\s*;';
- if ($line =~
/\b(kfree|usb_free_urb|debugfs_remove(?:_recursive)?)$expr/) {
- WARN('NEEDLESS_IF',
-"$1(NULL) is safe and this check is
probably not required\n" . $hereprev);
+ my $tested = quotemeta($1);
+ my $expr = '\s*\(\s*' . quotemeta($tested) .
'\s*\)\s*;';
+ if ($line =~
/\b(kfree|usb_free_urb|debugfs_remove(?:_recursive)?|(?:kmem_cache|mempool|dma_pool)_destroy)$expr/)
{
+ my $func = $1;
+ if (WARN('NEEDLESS_IF',
+"$func(NULL) is safe and this check is
probably not required\n" . $hereprev) &&
+ $fix) {
+ my $do_fix = 1;
+ my $leading_tabs = "";
+ my $new_leading_tabs = "";
+ if ($lines[$linenr - 2] =~
/^\+(\t*)if\s*\(\s*$tested\s*\)\s*$/) {
+ $leading_tabs = $1;
+ } else {
+ $do_fix = 0;
+ print("here1: <$lines[$linenr -
2]>\n")
+ }
+ if ($lines[$linenr - 1] =~
/^\+(\t+)$func\s*\(\s*$tested\s*\)\s*;\s*$/) {
+ $new_leading_tabs = $1;
+ if (length($leading_tabs) + 1
ne length($new_leading_tabs)) {
+ $do_fix = 0;
+ print("here2:
<$lines[$linenr - 1]>\n")
+ }
+ } else {
+ $do_fix = 0;
+ print("here3: <$lines[$linenr -
1]>\n")
+ }
+ if ($do_fix) {
+ fix_delete_line($fixlinenr - 1,
$prevrawline);
+ $fixed[$fixlinenr] =~
s/^\+$new_leading_tabs/\+$leading_tabs/;
+ }
+ }
}
}
--
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 RFC] net: phy: Introduced the PHY_AN_PENDING state
The PHY_AN_PENDING state is put as a gate to enter the PHY_AN state
where it will wait for any uncomplete auto-negotiation session to
finish before starting a new one.
This extra state could be used to workaround some auto-negotation
issues from certain vendors.
an_pending_timeout module parameter is used to enable the AN_PENDING
transition state. Set it to 0 to disable AN_PENDING state transition,
set it to any non-zero value to specify the timeout period for
PHY_AN_PENDING state in second. The default value is 0.
an_pending_guard module parameter serves as a guard band to delay
the auto-negotiation firing after the previous auto-negotiation
finish.
Signed-off-by: Keng Soon Cheah
Conflicts:
drivers/net/phy/phy.c
---
We observed failure in the ethernet link operation when our board pairs
with some network switch model. The problem happens when an
auto-negotiation is started around the time the previous auto-negotiation
complete. We believe this might be an interoperatibility issue between
the PHYs but we need a short-term solution in software to workaround the
issue.
We found that we are able to avoid from hitting the problem by waiting any
pending auto-negotiation to complete before starting a new one and this
patch is designed to serve the purpose.
A PHY_AN_PENDING state is introduced and it will act as a gate to enter
the PHY_AN state. This state will check for auto-negotiation completion
or timeout after an_pending_timeout period, then it will wait for
an_pending_guard before triggering another auto-negotiation.
The following diagram shows the timing diagram
an_pending_timeout an_pending_guard
V V auto-nego
|->||
^
auto-negotiation complete/timeout
We do not have plan to submit this patch upstream (unless the community
feels this patch is useful in general) but we would like to seek for
feedback or advice if this patch could introduce new problems.
---
drivers/net/phy/phy.c | 44 +++-
include/linux/phy.h |3 ++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index b2197b5..35e6484 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -38,6 +38,16 @@
#include
+static unsigned int an_pending_timeout;
+module_param(an_pending_timeout, uint, 0644);
+MODULE_PARM_DESC(an_pending_timeout,
+ "Timeout period for PHY_AN_PENDING state in second. 0 to disable
PHY_AN_PENDING state (default)");
+
+static unsigned int an_pending_guard;
+module_param(an_pending_guard, uint, 0644);
+MODULE_PARM_DESC(an_pending_guard,
+ "Guard band period before firing auto-negotiation from PHY_AN_PENDING
state in second. Default to 0");
+
static const char *phy_speed_to_str(int speed)
{
switch (speed) {
@@ -82,7 +92,6 @@ static const char *phy_state_to_str(enum phy_state st)
return NULL;
}
-
/**
* phy_print_status - Convenience function to print out the current phy status
* @phydev: the phy_device struct
@@ -485,6 +494,18 @@ int phy_start_aneg(struct phy_device *phydev)
/* Invalidate LP advertising flags */
phydev->lp_advertising = 0;
+ if (an_pending_timeout) {
+ switch (phydev->state) {
+ case PHY_AN_PENDING:
+ case PHY_HALTED:
+ break;
+ default:
+ phydev->state = PHY_AN_PENDING;
+ phydev->link_timeout = an_pending_timeout;
+ goto out_unlock;
+ }
+
+ }
err = phydev->drv->config_aneg(phydev);
if (err < 0)
@@ -831,6 +852,27 @@ void phy_state_machine(struct work_struct *work)
phydev->link_timeout = PHY_AN_TIMEOUT;
break;
+ case PHY_AN_PENDING:
+ /* Check if negotiation is done. Break if there's an error */
+ err = phy_aneg_done(phydev);
+ if (err < 0)
+ break;
+
+ /* If AN is done, we'll proceed with the real aneg triggering */
+ if (err > 0) {
+ if (phydev->link_timeout > 0)
+ phydev->link_timeout = -(an_pending_guard);
+ else if (phydev->link_timeout < 0)
+ phydev->link_timeout++;
+ } else
+ phydev->link_timeout--;
+
+ if (0 == phydev->link_timeout) {
+ needs_aneg = true;
+
+ phydev->link_timeout = PHY_AN_TIMEOUT;
+ }
+ break;
case PHY_AN:
err = phy_read_status(phydev);
if (err < 0)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index a26c3f8..a63afdc
Re: [RFC PATCH 07/18] kthread: Make iterant kthreads freezable by default
Hello, Petr. On Tue, Jun 09, 2015 at 05:53:13PM +0200, Petr Mladek wrote: > I think that the interaction with the hardware should be the reason to > make them properly freezable. In the current state they are stopped at > some random place, they might either miss some event from the hardware > or the hardware might get resumed into another state and the kthread > might wait forever. Yes, IIUC, there are two classes of use cases where freezing kthreads makes sense. * While hibernating, freezing writeback workers and whoever else which might issue IOs. This is because we have to thaw devices to issue IOs to write out the prepared hibernation image. If new IOs are issued from page cache or whereever when the devices are thawed for writing out the hibernation image, the hibernation image and the data on the disk deviate. Note that this only works because currently none of the block drivers which may be used to write out hibernation images depend on freezable kthreads and hopefully nobody issues IOs from unfreezable kthreads or bh or softirq, which, I think, can happen with preallocated requests or bio based devices. This is a very brittle approach. Instead of controlling things where it actually can be controlled - the IO ingress point - we're trying to control all its users with a pretty blunt tool while at the same time depending on the fact that some of the low level subsystems don't happen to make use of the said blunt tool. I think what we should do is simply blocking all non-image IOs from the block layer while writing out hibernation image. It'd be simpler and a lot more reliable. * Device drivers which interact with their devices in a fully synchronous manner so that blocking the kthread always reliably quiesces the device. For this to be true, the device shouldn't carry over any state across the freezing points. There are drivers which are actually like this and it works for them. However, my impression is that people don't really scrutinize why freezer works for a specific case and tend to spray them all over and develop a fuzzy sense that freezing will somehow magically make the driver ready for PM operatoins. It doesn't help that freezer is such a blunt tool and our historical usage has always been fuzzy - in the earlier days, we depended on freezer even when we knew it wasn't sufficient probably because updating all subsystems and drivers were such a huge undertaking and freezer kinda sorta works in many cases. IMHO we'd be a lot better served by blocking the kthread from PM callbacks explicitly for these drivers to unify control points for PM operations and make what's going on a lot more explicit. This will surely involve a bit more boilerplate code but with the right helpers it should be mostly trivial and I believe that it's likely to encourage higher quality PM operations why getting rid of this fuzzy feeling around the freezer. For both cases, I don't really think kthread freezer is a good solution. This is a blunt enough tool to hide problems in most but not all cases while unnecessarily obscuring what's going on from developers. I personally strongly think that we eventually need to get rid of the kernel part of freezer. > Also I think that freezing kthreads on some well defined location > should help with reproducing and fixing problems. > > Note that _only_ kthreads using the _new API_ should be freezable by > default. The move need to be done carefully. It is chance to review > and clean up the freezer stuff. > > Of course, I might be too optimistic here. I'm strongly against this. We really don't want to make it even fuzzier. There are finite things which need to be controlled for PM operations and I believe what we need to do is identifying them and implementing explicit and clear control mechanisms for them, not spreading this feel-good mechanism even more, further obscuring where those points are. This becomes the game of "is it frozen ENOUGH yet?" and that "enough" is extremely difficult to determine as we're not looking at the choke spots at all and freezable kthreads only cover part of kernel activity. The fuzzy enoughness also actually inhibits development of proper mechanisms - "I believe this is frozen ENOUGH at this point so it is probably safe to assume that X, Y and Z aren't happening anymore" and it usually is except when it's not. Let's please not spread this even more. > > In most cases, we want to implement proper power management callbacks > > which plug new issuance of whatever work-unit the code is dealing with > > and drain in-flight ones. Whether the worker threads are frozen or > > not doesn't matter once that's implemented. > > I see. The power management is important here. That's the only reason we have freezer at all. > > It seems that people have been marking kthreads freezable w/o really > > thinking about it - some of them are subtly broken due to
Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
Hi Guenter, On 10 June 2015 at 11:41, Fu Wei wrote: > Hi Guenter, > > On 10 June 2015 at 00:45, Guenter Roeck wrote: >> On 06/09/2015 09:29 AM, Timur Tabi wrote: >>> >>> On 06/09/2015 11:22 AM, Guenter Roeck wrote: but I see your point. Essentially, the specification is broken for all practical purposes, since, as you point out, enabling the watchdog overwrites and explicitly sets WCV. Effectively this means that just using WCV to program the timeout period is not really possible. I am not really sure how to address this. We can either only use WOR, and forget about pretimeout, or we can enforce a minimum pretimeout. In the latter case, we'll have to write WCV after writing WOR. >>> >>> >>> In talking with our hardware engineers, using WCV to program the timeout >>> period is not a valid operation. This is why I keep arguing against the >>> pre-timeout feature, and I don't agree that servers should always use >>> pre-timeout. >>> >> >> Not sure if "not valid" is correct - after all, it is mentioned in the >> specification. However, it is at the very least fragile. > > I think we should focus on SBSA spec, but not a specific chip design, > because this is SBSA watchdog, not a driver for an IP core from a > specific chip vendor. > this operation is mentioned in the spec, > and I have tested my driver on Foundation model(from ARM) and a real hardware. > >> >> I tend to agree that we should just forget about pretimeout and >> use your original approach, where the timeout value is used >> to program WOR. Everything else is really just asking for trouble. Another weakness of only using WOR is the timeout limited by this 32bit register. 10s @400MHz generic Timer I don't think this limit is good for a server, once the server is in a heavy load > > I don't mind if we give up pretimeout, The reason I use pretimeout is: > this concept matches the function of two stage timeouts. > > but, If we give up pretimeout, could you give me a suggestion: > > How to config the two stage timeouts > (1)from enabling watchdog to WS0 > (2)the time from WS1 to WS0 > > If we only have one timeout parameter, How to config the two stage timeouts? > Any suggestion ? > > If we make the first stage timeout is timeout/2, this violates the > definition of timeout. > I don't think users expect interrupt, panic or reboot at timeout/2. > > And WS1 definitely isn't a backup of WS0. > >> >> Guenter >> > > > > -- > Best regards, > > Fu Wei > Software Engineer > Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch > Ph: +86 21 61221326(direct) > Ph: +86 186 2020 4684 (mobile) > Room 1512, Regus One Corporate Avenue,Level 15, > One Corporate Avenue,222 Hubin Road,Huangpu District, > Shanghai,China 200021 -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- 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] Doc:pps: Fix typo in pps.txt
This patch fix a spelling typo in Documentation/pps/pps.txt Signed-off-by: Masanari Iida --- Documentation/pps/pps.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt index c03b1be..a811307 100644 --- a/Documentation/pps/pps.txt +++ b/Documentation/pps/pps.txt @@ -166,7 +166,7 @@ Testing the PPS support In order to test the PPS support even without specific hardware you can use the ktimer driver (see the client subsection in the PPS configuration menu) -and the userland tools provided into Documentaion/pps/ directory. +and the userland tools provided into Documentation/pps/ directory. Once you have enabled the compilation of ktimer just modprobe it (if not statically compiled): -- 2.4.2.387.gf86f31a -- 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 char-misc-next 2/2] misc: mic: Fix reported static checker warning
Delete unnecessary prints resulting in an "spdev could be null" warning from a static checker in scif_peer_remove(..). Reported-by: Dan Carpenter Reviewed-by: Ashutosh Dixit Signed-off-by: Sudeep Dutt --- drivers/misc/mic/scif/scif_main.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/misc/mic/scif/scif_main.c b/drivers/misc/mic/scif/scif_main.c index f7187dc..6ce851f 100644 --- a/drivers/misc/mic/scif/scif_main.c +++ b/drivers/misc/mic/scif/scif_main.c @@ -91,8 +91,6 @@ static int scif_peer_probe(struct scif_peer_dev *spdev) rcu_assign_pointer(scifdev->spdev, spdev); /* In the future SCIF kernel client devices will be added here */ - dev_info(>dev, "Peer added dnode %d\n", -spdev->dnode); return 0; } @@ -109,8 +107,6 @@ static void scif_peer_remove(struct scif_peer_dev *spdev) mutex_lock(_info.conflock); scif_info.total--; mutex_unlock(_info.conflock); - dev_info(>dev, "Peer removed dnode %d\n", -spdev->dnode); } static void scif_qp_setup_handler(struct work_struct *work) -- 1.8.2.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] treewide: Fix typo compatability -> compatibility
On Wed, Jun 10, 2015 at 7:27 AM, Mauro Carvalho Chehab wrote: > Em Wed, 27 May 2015 15:05:42 +0300 > Laurent Pinchart escreveu: > >> Even though 'compatability' has a dedicated entry in the Wiktionary, >> it's listed as 'Mispelling of compatibility'. Fix it. >> >> Signed-off-by: Laurent Pinchart > > Acked-by: Mauro Carvalho Chehab > >> --- >> arch/metag/include/asm/elf.h | 2 +- >> arch/powerpc/kvm/book3s.c| 2 +- >> arch/sparc/include/uapi/asm/pstate.h | 2 +- >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- >> drivers/media/dvb-frontends/au8522_dig.c | 2 +- >> drivers/net/wireless/ipw2x00/ipw2100.h | 2 +- >> 6 files changed, 7 insertions(+), 7 deletions(-) >> >> I can split this into one patch per subsystem, but that seems a bit overkill. >> Can someone take it ? > > Who? That's the problem with treewide patches ;) > > Perhaps you should re-submit it with the acks you got to akpm. > > Regards, > Mauro > Laurent, Please re-submit your patch to triv...@kernel.org with [trivial] in the title. Ex. [PATCH] [trivial] treewide: Fix typo compatability -> compatibility Regards, Masanari -- 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 char-misc-next 0/2] misc: mic: bug fixes
This patch series fixes reported issues including a randconfig build error and a warning from a static checker. Sudeep Dutt (2): misc: mic: Fix randconfig build error by including errno.h misc: mic: Fix reported static checker warning drivers/misc/mic/scif/scif_main.c | 4 drivers/misc/mic/scif/scif_rb.c | 1 + 2 files changed, 1 insertion(+), 4 deletions(-) -- 1.8.2.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 char-misc-next 1/2] misc: mic: Fix randconfig build error by including errno.h
This issue was reported @ https://lkml.org/lkml/2015/6/9/731 Reported-by: Jim Davis Reviewed-by: Ashutosh Dixit Signed-off-by: Sudeep Dutt --- drivers/misc/mic/scif/scif_rb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/mic/scif/scif_rb.c b/drivers/misc/mic/scif/scif_rb.c index 47de222..637cc46 100644 --- a/drivers/misc/mic/scif/scif_rb.c +++ b/drivers/misc/mic/scif/scif_rb.c @@ -18,6 +18,7 @@ #include #include #include +#include #include "scif_rb.h" -- 1.8.2.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: [RFC PATCH v6 25/32] perf tools: Add 'bpf.' config section to perf default config
On 6/9/15 7:23 PM, Wangnan (F) wrote: I'll embed this script in my next version. fine, let's use the script for now and inform the user that they would need to manually copy the flags into .perfconfig -- 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 5/7] Watchdog: introduce ARM SBSA watchdog driver
Hi Guenter, On 10 June 2015 at 00:45, Guenter Roeck wrote: > On 06/09/2015 09:29 AM, Timur Tabi wrote: >> >> On 06/09/2015 11:22 AM, Guenter Roeck wrote: >>> >>> >>> >>> but I see your point. Essentially, the specification is broken >>> for all practical purposes, since, as you point out, enabling >>> the watchdog overwrites and explicitly sets WCV. Effectively >>> this means that just using WCV to program the timeout period >>> is not really possible. >>> >>> I am not really sure how to address this. We can either only use WOR, >>> and forget about pretimeout, or we can enforce a minimum pretimeout. >>> In the latter case, we'll have to write WCV after writing WOR. >> >> >> In talking with our hardware engineers, using WCV to program the timeout >> period is not a valid operation. This is why I keep arguing against the >> pre-timeout feature, and I don't agree that servers should always use >> pre-timeout. >> > > Not sure if "not valid" is correct - after all, it is mentioned in the > specification. However, it is at the very least fragile. I think we should focus on SBSA spec, but not a specific chip design, because this is SBSA watchdog, not a driver for an IP core from a specific chip vendor. this operation is mentioned in the spec, and I have tested my driver on Foundation model(from ARM) and a real hardware. > > I tend to agree that we should just forget about pretimeout and > use your original approach, where the timeout value is used > to program WOR. Everything else is really just asking for trouble. I don't mind if we give up pretimeout, The reason I use pretimeout is: this concept matches the function of two stage timeouts. but, If we give up pretimeout, could you give me a suggestion: How to config the two stage timeouts (1)from enabling watchdog to WS0 (2)the time from WS1 to WS0 If we only have one timeout parameter, How to config the two stage timeouts? Any suggestion ? If we make the first stage timeout is timeout/2, this violates the definition of timeout. I don't think users expect interrupt, panic or reboot at timeout/2. And WS1 definitely isn't a backup of WS0. > > Guenter > -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- 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] cpufreq: mediatek: Add MT8173 cpufreq driver
On Tue, Jun 9, 2015 at 5:17 PM, Paul Bolle wrote: > On Mon, 2015-06-08 at 20:29 +0800, Pi-Cheng Chen wrote: >> --- /dev/null >> +++ b/drivers/cpufreq/mt8173-cpufreq.c > >> +#include > > Weren't you going to drop this include? Sorry I forget to merge that part of fix into this patch. Will fix it. > >> +module_init(mt8173_cpufreq_driver_init); > > For built-in code this is equivalent to, speaking from memory: > device_initcall(mt8173_cpufreq_driver_init); > > Why don't you just use that directly? Yes. Will do it. Thanks for reviewing. Best Regards, Pi-Cheng > > Thanks, > > > Paul Bolle > -- 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 05/36] HMM: introduce heterogeneous memory management v3.
On Tue, 9 Jun 2015, Jerome Glisse wrote: > On Mon, Jun 08, 2015 at 06:54:29PM -0700, Mark Hairgrove wrote: > > Can you clarify how that's different from mmu_notifiers? Those are also > > embedded into a driver-owned struct. > > For HMM you want to be able to kill a mirror from HMM, you might have kernel > thread call inside HMM with a mirror (outside any device file lifetime) ... > The mirror is not only use at register & unregister, there is a lot more thing > you can call using the HMM mirror struct. > > So the HMM mirror lifetime as a result is more complex, it can not simply be > free from the mmu_notifier_release callback or randomly. It needs to be > refcounted. Sure, there are driver -> HMM calls like hmm_mirror_fault that mmu_notifiers don't have, but I don't understand why that fundamentally makes HMM mirror lifetimes more complex. Decoupling hmm_mirror lifetime from mm lifetime adds complexity too. > The mmu_notifier code assume that the mmu_notifier struct is > embedded inside a struct that has a lifetime properly synchronize with the > mm. For HMM mirror this is not something that sounds like a good idea as there > is too many way to get it wrong. What kind of synchronization with the mm are you referring to here? Clients of mmu_notifiers don't have to do anything as far as I know. They're guaranteed that the mm won't go away because each registered notifier bumps mm_count. > So idea of HMM mirror is that it can out last the mm lifetime but the HMM > struct can not. So you have hmm_mirror <~> hmm <-> mm and the mirror can be > "unlink" and have different lifetime from the hmm that itself has same life > time as mm. Per the earlier discussion hmm_mirror_destroy is missing a call to hmm_unref. If that's added back I don't understand how the mirror can persist past the hmm struct. The mirror can be unlinked from hmm's list, yes, but that doesn't mean that hmm/mm can be torn down. The hmm/mm structs will stick around until hmm_destroy since that does the mmu_notifier_unregister. hmm_destroy can't be called until the last hmm_mirror_destroy. Doesn't that mean that hmm/mm are guaranteed to be allocated until the last hmm_mirror_unregister? That sounds like a good guarantee to make. > > > Is the goal to allow calling hmm_mirror_unregister from within the "mm is > > dying" HMM callback? I don't know whether that's really necessary as long > > as there's some association between the driver files and the mirrors. > > No this is not a goal and i actualy forbid that. > > > > > > > If so, I think there's a race here in the case of mm teardown happening > > > > concurrently with hmm_mirror_unregister. > > > > > > > > [...] > > > > > > > > Do you agree that this sequence can happen, or am I missing something > > > > which prevents it? > > > > > > Can't happen because child have mm->hmm = NULL ie only one hmm per mm > > > and hmm is tie to only one mm. It is the responsability of the device > > > driver to make sure same apply to private reference to the hmm mirror > > > struct ie hmm_mirror should never be tie to a private file struct. > > > > It's useful for the driver to have some association between files and > > mirrors. If the file is closed prior to process exit we would like to > > unregister the mirror, otherwise it will persist until process teardown. > > The association doesn't have to be 1:1 but having the files ref count the > > mirror or something would be useful. > > This is allowed, i might have put strong word here, but you can associate > with a file struct. What you can not do is use the mirror from a different > process ie one with a different mm struct as mirror is linked to a single > mm. So on fork there is no callback to update the private file struct, when > the device file is duplicated (well just refcount inc) against a different > process. This is something you need to be carefull in your driver. Inside > the dummy driver i abuse that to actually test proper behavior of HMM but > it should not be use as an example. So to confirm, on all file operations from user space the driver is expected to check that current->mm matches the mm associated with the struct file's hmm_mirror? On file->release the driver still ought to call hmm_mirror_unregister regardless of whether the mms match, otherwise we'll never tear down the mirror. That means we're not saved from the race condition because hmm_mirror_unregister can happen in one thread while hmm_notifier_release might be happening in another thread. > > > > But even if we assume no association at all between files and mirrors, are > > you sure that prevents the race? The driver may choose to unregister the > > hmm_device at any point once its files are closed. In the case of module > > unload the device unregister can't be prevented. If mm teardown hasn't > > happened yet mirrors may still be active and registered on that > > hmm_device. The driver thus has to first call hmm_mirror_unregister on
Re: clustered MD
On 06/09/2015 03:30 PM, David Teigland wrote: On Tue, Jun 09, 2015 at 03:08:11PM -0500, Goldwyn Rodrigues wrote: Hi David, On 06/09/2015 02:45 PM, David Teigland wrote: On Tue, Jun 09, 2015 at 02:26:25PM -0500, Goldwyn Rodrigues wrote: On 06/09/2015 01:22 PM, David Teigland wrote: I've just noticed the existence of clustered MD for the first time. It is a major new user of the dlm, and I have some doubts about it. When did this appear on the mailing list for review? It first appeared in December, 2014 on the RAID mailing list. http://marc.info/?l=linux-raid=141891941330336=2 I don't read that mailing list. Searching my archives of linux-kernel, it has never been mentioned. I can't even find an email for the md pull request that included it. Is this what you are looking for? http://marc.info/?l=linux-kernel=142976971510061=2 Yes, I guess gmail lost it, or put it in spam. - "experimental" code for managing md/raid1 across a cluster using DLM. Code is not ready for general use and triggers a WARNING if used. However it is looking good and mostly done and having in mainline will help co-ordinate development. That falls far short of the bar for adding it to the kernel. It not only needs to work, it needs to be reviewed and justified, usually by showing Why do you say it does not work? It's just my abbreviation of that summary paragraph. It did go through it's round of reviews on the RAID mailing list. I understand that you missed it because you are not subscribed to the raid mailing list. I will look for that. some real world utility to warrant the potential maintenance effort. We do have a valid real world utility. It is to provide high-availability of RAID1 storage over the cluster. The distributed locking is required only during cases of error and superblock updates and is not required during normal operations, which makes it fast enough for usual case scenarios. That's the theory, how much evidence do you have of that in practice? We wanted to develop a solution which is lock free (or atleast minimum) for the most common/frequent usage scenario. Also, we compared it with iozone on top of ocfs2 to find that it is very close to local device performance numbers. we compared it with cLVM mirroring to find it better as well. However, in the future we would want to use it with with other RAID (10?) scenarios which is missing now. What are the doubts you have about it? Before I begin reviewing the implementation, I'd like to better understand what it is about the existing raid1 that doesn't work correctly for what you'd like to do with it, i.e. I don't know what the problem is. David Lang has already responded: The idea is to use a RAID device (currently only level 1 mirroring is supported) with multiple nodes of the cluster. Here is a description on how to use it: http://marc.info/?l=linux-raid=141935561418770=2 -- Goldwyn -- 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 3/4] HID: hid-sony: PS3 Move enable LEDs and Rumble via BT
The LED and Rumble control only function via BT if the full output report
is sent. The large report still functions via USB.
Signed-off-by: Simon Wood
---
drivers/hid/hid-sony.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index d9fa804..51cb1ac 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -902,6 +902,7 @@ struct motion_output_report_02 {
#define DS4_REPORT_0x81_SIZE 7
#define SIXAXIS_REPORT_0xF2_SIZE 17
#define SIXAXIS_REPORT_0xF5_SIZE 8
+#define MOTION_REPORT_0x02_SIZE 49
static DEFINE_SPINLOCK(sony_dev_list_lock);
static LIST_HEAD(sony_device_list);
@@ -1746,7 +1747,7 @@ static void motion_state_worker(struct work_struct *work)
struct motion_output_report_02 *report =
(struct motion_output_report_02 *)sc->output_report_dmabuf;
- memset(report, 0, sizeof(struct motion_output_report_02));
+ memset(report, 0, MOTION_REPORT_0x02_SIZE);
report->type = 0x02; /* set leds */
report->r = sc->led_state[0];
@@ -1757,8 +1758,7 @@ static void motion_state_worker(struct work_struct *work)
report->rumble = max(sc->right, sc->left);
#endif
- hid_hw_output_report(hdev, (__u8 *)report,
- sizeof(struct motion_output_report_02));
+ hid_hw_output_report(hdev, (__u8 *)report, MOTION_REPORT_0x02_SIZE);
}
static int sony_allocate_output_report(struct sony_sc *sc)
@@ -1774,9 +1774,8 @@ static int sony_allocate_output_report(struct sony_sc *sc)
sc->output_report_dmabuf = kmalloc(DS4_REPORT_0x05_SIZE,
GFP_KERNEL);
else if (sc->quirks & MOTION_CONTROLLER)
- sc->output_report_dmabuf =
- kmalloc(sizeof(struct motion_output_report_02),
- GFP_KERNEL);
+ sc->output_report_dmabuf = kmalloc(MOTION_REPORT_0x02_SIZE,
+ GFP_KERNEL);
else
return 0;
--
2.1.4
--
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 1/4] HID: hid-sony: Add quirk for MOTION_CONTROLLER_BT
Split quirk for PS Move Controller as it has to be treated differently
when connected via BT.
Signed-off-by: Simon Wood
---
drivers/hid/hid-sony.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 6fcc2b4..28dba6c 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -46,9 +46,11 @@
#define PS3REMOTE BIT(4)
#define DUALSHOCK4_CONTROLLER_USB BIT(5)
#define DUALSHOCK4_CONTROLLER_BT BIT(6)
-#define MOTION_CONTROLLER BIT(7)
+#define MOTION_CONTROLLER_USB BIT(7)
+#define MOTION_CONTROLLER_BT BIT(8)
#define SIXAXIS_CONTROLLER (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT)
+#define MOTION_CONTROLLER (MOTION_CONTROLLER_USB | MOTION_CONTROLLER_BT)
#define DUALSHOCK4_CONTROLLER (DUALSHOCK4_CONTROLLER_USB |\
DUALSHOCK4_CONTROLLER_BT)
#define SONY_LED_SUPPORT (SIXAXIS_CONTROLLER | BUZZ_CONTROLLER |\
@@ -2261,9 +2263,9 @@ static const struct hid_device_id sony_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER),
.driver_data = SIXAXIS_CONTROLLER_USB },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_MOTION_CONTROLLER),
- .driver_data = MOTION_CONTROLLER },
+ .driver_data = MOTION_CONTROLLER_USB },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_MOTION_CONTROLLER),
- .driver_data = MOTION_CONTROLLER },
+ .driver_data = MOTION_CONTROLLER_BT },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_PS3_CONTROLLER),
.driver_data = SIXAXIS_CONTROLLER_BT },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE),
--
2.1.4
--
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 4/4] HID: hid-sony: PS Move fix report descriptor
Fix the report descriptor so that the buttons and trigger are correctly
reported.
The format of the input report is described here:
https://github.com/nitsch/moveonpc/wiki/Input-report
The Accelerometers and Gyros (1st frame only) are also reported as axis, but
the Magnetometers are NOT as 'fixing' their byte order would break user-space
drivers such as PSMoveAPI.
It is hoped to resolve this at a future time.
Signed-off-by: Simon Wood
---
drivers/hid/hid-sony.c | 69 --
1 file changed, 44 insertions(+), 25 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 51cb1ac..2ce0295 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -153,52 +153,71 @@ static __u8 motion_rdesc[] = {
0xA1, 0x01, /* Collection (Application), */
0xA1, 0x02, /* Collection (Logical), */
0x85, 0x01, /* Report ID (1), */
- 0x75, 0x08, /* Report Size (8),*/
- 0x95, 0x01, /* Report Count (1), */
- 0x15, 0x00, /* Logical Minimum (0),*/
- 0x26, 0xFF, 0x00, /* Logical Maximum (255), */
- 0x81, 0x03, /* Input (Constant, Variable), */
0x75, 0x01, /* Report Size (1),*/
- 0x95, 0x13, /* Report Count (19), */
+ 0x95, 0x15, /* Report Count (21), */
0x15, 0x00, /* Logical Minimum (0),*/
0x25, 0x01, /* Logical Maximum (1),*/
0x35, 0x00, /* Physical Minimum (0), */
0x45, 0x01, /* Physical Maximum (1), */
0x05, 0x09, /* Usage Page (Button),*/
0x19, 0x01, /* Usage Minimum (01h),*/
- 0x29, 0x13, /* Usage Maximum (13h),*/
- 0x81, 0x02, /* Input (Variable), */
- 0x75, 0x01, /* Report Size (1),*/
- 0x95, 0x0D, /* Report Count (13), */
+ 0x29, 0x15, /* Usage Maximum (15h),*/
+ 0x81, 0x02, /* Input (Variable), * Buttons */
+ 0x95, 0x0B, /* Report Count (11), */
0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
- 0x81, 0x03, /* Input (Constant, Variable), */
+ 0x81, 0x03, /* Input (Constant, Variable), * Padding */
0x15, 0x00, /* Logical Minimum (0),*/
0x26, 0xFF, 0x00, /* Logical Maximum (255), */
0x05, 0x01, /* Usage Page (Desktop), */
- 0x09, 0x01, /* Usage (Pointer),*/
0xA1, 0x00, /* Collection (Physical), */
0x75, 0x08, /* Report Size (8),*/
- 0x95, 0x04, /* Report Count (4), */
+ 0x95, 0x01, /* Report Count (1), */
0x35, 0x00, /* Physical Minimum (0), */
0x46, 0xFF, 0x00, /* Physical Maximum (255), */
0x09, 0x30, /* Usage (X), */
- 0x09, 0x31, /* Usage (Y), */
- 0x09, 0x32, /* Usage (Z), */
- 0x09, 0x35, /* Usage (Rz), */
- 0x81, 0x02, /* Input (Variable), */
+ 0x81, 0x02, /* Input (Variable), * Trigger */
0xC0, /* End Collection, */
- 0x05, 0x01, /* Usage Page (Desktop), */
- 0x95, 0x13, /* Report Count (19), */
- 0x09, 0x01, /* Usage (Pointer),*/
+ 0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
+ 0x75, 0x08, /* Report Size (8),*/
+ 0x95, 0x07, /* Report Count (7), * skip 7
bytes */
0x81, 0x02, /* Input (Variable), */
- 0x95, 0x0C, /* Report Count (12), */
- 0x81, 0x01, /* Input (Constant), */
+ 0x05, 0x01, /* Usage Page (Desktop), */
0x75, 0x10, /* Report Size (16), */
- 0x95, 0x04, /* Report Count (4), */
- 0x26, 0xFF, 0x03, /* Logical Maximum (1023), */
- 0x46, 0xFF, 0x03, /* Physical Maximum (1023),*/
+ 0x46, 0xFF, 0xFF, /* Physical
[PATCH 2/4] HID_ hid-sony_ Add support PS3 Move Battery via BT
Add support for the battery charge level and state to be read via BT.
This is not support via USB as there is no know way to get the device
sending 'input' reports over USB.
Signed-off-by: Simon Wood
---
drivers/hid/hid-sony.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 28dba6c..d9fa804 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -55,7 +55,8 @@
DUALSHOCK4_CONTROLLER_BT)
#define SONY_LED_SUPPORT (SIXAXIS_CONTROLLER | BUZZ_CONTROLLER |\
DUALSHOCK4_CONTROLLER | MOTION_CONTROLLER)
-#define SONY_BATTERY_SUPPORT (SIXAXIS_CONTROLLER | DUALSHOCK4_CONTROLLER)
+#define SONY_BATTERY_SUPPORT (SIXAXIS_CONTROLLER | DUALSHOCK4_CONTROLLER |\
+ MOTION_CONTROLLER_BT)
#define SONY_FF_SUPPORT (SIXAXIS_CONTROLLER | DUALSHOCK4_CONTROLLER |\
MOTION_CONTROLLER)
@@ -1041,6 +1042,7 @@ static void sixaxis_parse_report(struct sony_sc *sc, __u8
*rd, int size)
{
static const __u8 sixaxis_battery_capacity[] = { 0, 1, 25, 50, 75, 100
};
unsigned long flags;
+ int offset;
__u8 cable_state, battery_capacity, battery_charging;
/*
@@ -1049,12 +1051,14 @@ static void sixaxis_parse_report(struct sony_sc *sc,
__u8 *rd, int size)
* It does not report the actual level while charging so it
* is set to 100% while charging is in progress.
*/
- if (rd[30] >= 0xee) {
+ offset = (sc->quirks & MOTION_CONTROLLER) ? 12 : 30;
+
+ if (rd[offset] >= 0xee) {
battery_capacity = 100;
- battery_charging = !(rd[30] & 0x01);
+ battery_charging = !(rd[offset] & 0x01);
cable_state = 1;
} else {
- __u8 index = rd[30] <= 5 ? rd[30] : 5;
+ __u8 index = rd[offset] <= 5 ? rd[offset] : 5;
battery_capacity = sixaxis_battery_capacity[index];
battery_charging = 0;
cable_state = 0;
@@ -1155,6 +1159,8 @@ static int sony_raw_event(struct hid_device *hdev, struct
hid_report *report,
swap(rd[47], rd[48]);
sixaxis_parse_report(sc, rd, size);
+ } else if ((sc->quirks & MOTION_CONTROLLER_BT) && rd[0] == 0x01 && size
== 49) {
+ sixaxis_parse_report(sc, rd, size);
} else if (((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && rd[0] == 0x01 &&
size == 64) || ((sc->quirks & DUALSHOCK4_CONTROLLER_BT)
&& rd[0] == 0x11 && size == 78)) {
@@ -1976,6 +1982,7 @@ static int sony_check_add(struct sony_sc *sc)
int n, ret;
if ((sc->quirks & DUALSHOCK4_CONTROLLER_BT) ||
+ (sc->quirks & MOTION_CONTROLLER_BT) ||
(sc->quirks & SIXAXIS_CONTROLLER_BT)) {
/*
* sony_get_bt_devaddr() attempts to parse the Bluetooth MAC
--
2.1.4
--
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: [RFC PATCH 06/18] signal/kthread: Initial implementation of kthread signal handling
Hello, Jiri. On Tue, Jun 09, 2015 at 02:15:24PM +0200, Jiri Kosina wrote: > To me, the ultimate goal (*) is to make it possible for kthread to be able > to decide whether it wants "some kind of default behavior" (however that'd > be defined), or "ignore all", or "just handle this set of signals with > these handlers", and make API for this that would avoid every kthread > implementing its own complete signal handling. Yes, cleaning up the current usages like above would be great but one concern is that the above might inadvertantly encourage usage of signals in kthreads which I don't think is a good idea. It'd be great if we can consolidate the current users while also making it clear that we shouldn't be adding new ones. > > While we do have several kthread signal users, they aren't too many and > > majority of them use it to allow userland to tell it to shutdown and > > Yeah. Via SIGKILL. Or SIGTERM. Or SIGINT. Or SIGQUIT. Not really > consistent either. Exactly, and it's pretty confusing from userland. Why do some kthreads take SIGTERM but not SIGKILL while others do the other way and yet others ignore them all? This is too low level for a userland visible interface which is tied too closely to the implementation detail (usage of one kthread) and often unclear in terms of the meaning of the action. > > there seem to be a couple which use HUP/USR1 to cancel whatever it's > > processing / waiting on at the moment. Hmmm... jffs uses STOP/CONT too. > > > I don't know how this should be done but let's please try to > > > > 1. Encourage uniform behaviors across the signals. > > Fully agreed. > > > 2. Ultimately discourage usage of signals on kthreads as this closely > >ties implementation detail (use of single kthread) to the userland > >visible interface in a way where we can't easily get back out of. > >For example, what if jffs needs its gc workers to be multi-threaded > >and per-NUMA for high-iops devices later on? > > What kind of multi-threading kthreads are you referring to here? Something > more sophisticated than simply spawning several per-CPU (or > per-whatever-resource) full-fledged kthreads? Becoming simple multi-threaded or per-cpu are good examples but these things not too rarely develop into something which needs more sophiscation. e.g. jobs which process considerable amount data are usually best served by NUMA-node-affine workers roughly matching the number of CPUs in each node. workqueue is half way there but still lacking an automatic way to regulate concurrency in those cases. For certain use cases, you really can't avoid employing a pool of workers and once things get there, having tied userland interface to a single kthread becomes pretty awkward. It sure works for certain use cases and sending signals to kthreads *might* be considered a "softer" interface where userland is meddling with kernel implementation details that it can be changed later on but it can still be painful for users depending on it. Thanks. -- tejun -- 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: [Cluster-devel] [PATCH] dlm: remove unnecessary error check
Bob Peterson wrote: > - Original Message - > >> Hi Bob, >> >> Bob Peterson wrote: >> >>> - Original Message - >>> >>> We don't need the redundant logic since send_message always returns 0. Signed-off-by: Guoqing Jiang --- fs/dlm/lock.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 35502d4..6fc3de9 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -3656,10 +3656,7 @@ static int send_common(struct dlm_rsb *r, struct dlm_lkb *lkb, int mstype) send_args(r, lkb, ms); - error = send_message(mh, ms); - if (error) - goto fail; - return 0; + return send_message(mh, ms); fail: remove_from_waiters(lkb, msg_reply_type(mstype)); @@ -3763,10 +3760,7 @@ static int send_lookup(struct dlm_rsb *r, struct dlm_lkb *lkb) send_args(r, lkb, ms); - error = send_message(mh, ms); - if (error) - goto fail; - return 0; + return send_message(mh, ms); fail: remove_from_waiters(lkb, DLM_MSG_LOOKUP_REPLY); -- 1.7.12.4 >>> Hi, >>> >>> The patch looks okay, but if remove_from_waiters() always returns 0, >>> wouldn't it be better to change the function from int to void and >>> return 0 here? The advantage is that code spelunkers wouldn't need >>> to back-track one more level (not to mention the instruction or two >>> it might save). >>> >>> >>> >> Seems remove_from_waiters is not always returns 0, the return value >> could be -1 or 0 which depends on _remove_from_waiters. >> >> BTW, I found that there are no big difference between send_common >> and send_lookup, since the send_common can also be use to send >> lookup message, I guess send_lookup can be removed as well. >> >> Thanks, >> Guoqing >> > > Hi Guoqing, > > If remove_from_waiters can return -1, then the patch would prevent the > code from calling remove_from_waiters. So the patch still doesn't look > right to me. > > Hi Bob, The remove_from_waiters could only be invoked after failed to create_message, right? Since send_message always returns 0, this patch doesn't touch anything about the failure path, and it also doesn't change the original semantic. Thanks, Guoqing -- 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 kernel] powerpc/powernv: Fix crash when CONFIG_IOMMU_API is off
The code introduced in "[PATCH kernel v12 17/34] powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group" checks that an IOMMU group was registered for the specific table group which is not true when CONFIG_IOMMU_API is off as iommu_register_group() is a stub in this case. This makes BUG_ON conditional. Signed-off-by: Alexey Kardashevskiy --- arch/powerpc/platforms/powernv/pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c index 4b4c583..a57554a 100644 --- a/arch/powerpc/platforms/powernv/pci.c +++ b/arch/powerpc/platforms/powernv/pci.c @@ -624,8 +624,9 @@ long pnv_pci_link_table_and_group(int node, int num, BUG_ON(!tbl); BUG_ON(!table_group); +#ifdef CONFIG_IOMMU_API BUG_ON(!table_group->group); - +#endif tgl = kzalloc_node(sizeof(struct iommu_table_group_link), GFP_KERNEL, node); if (!tgl) -- 2.4.0.rc3.8.gfb3e7d5 -- 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: [ANNOUNCE] 4.0.4-rt1
On 06/09/2015 03:05 PM, Pavel Vasilyev wrote: 09.06.2015 19:45, Fernando Lopez-Lezcano пишет: This is still happening, about once a day. John Dulaney help me set up a crash kernel dump (thanks!) so now I have a kernel core dump for this one, Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime system? :D :-P Yup. I have been using rt for many years - and packaging it - for (very) low latency sound processing. Linux + rt + jackd + rtirq + threaded irqs + jack clients, everything with the right priorities. Runs very nicely unless you hit an issue like the one I'm asking about[*]. Usually running snd_hdspm with RME hardware when in concert situations (this one with Asus mobo is my - quite old by now - desktop at work, but I'm also having the same problem in my Lenovo laptop). -- Fernando [*] for example a whole concert for a 24.8 3D sound system with a remote ethernet driven D/A and running all the time with 64 frame x 2 buffers at 48KHz. -- 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: [RFC PATCH 08/12] mm: use mirrorable to switch allocate mirrored memory
On 2015/06/09 19:09, Xishi Qiu wrote: On 2015/6/9 15:06, Kamezawa Hiroyuki wrote: On 2015/06/04 22:02, Xishi Qiu wrote: Add a new interface in path /proc/sys/vm/mirrorable. When set to 1, it means we should allocate mirrored memory for both user and kernel processes. Signed-off-by: Xishi Qiu I can't see why do we need this switch. If this is set, all GFP_HIGHUSER will use mirrored memory ? Or will you add special MMAP/madvise flag to use mirrored memory ? Hi Kame, Yes, MMAP/madvise -> add VM_MIRROR -> add GFP_MIRROR -> use MIGRATE_MIRROR list to alloc mirrored pages So user can use mirrored memory. What do you think? I see. please explain it (your final plan) in patch description or in cover page of patches. Thanks, -Kame -- 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: [RFC PATCH 01/12] mm: add a new config to manage the code
On 2015/06/09 19:10, Xishi Qiu wrote: On 2015/6/9 14:44, Kamezawa Hiroyuki wrote: On 2015/06/04 21:56, Xishi Qiu wrote: This patch introduces a new config called "CONFIG_ACPI_MIRROR_MEMORY", it is used to on/off the feature. Signed-off-by: Xishi Qiu --- mm/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/mm/Kconfig b/mm/Kconfig index 390214d..4f2a726 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -200,6 +200,14 @@ config MEMORY_HOTREMOVE depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE depends on MIGRATION +config MEMORY_MIRROR +bool "Address range mirroring support" +depends on X86 && NUMA +default y +help + This feature depends on hardware and firmware support. + ACPI or EFI records the mirror info. default y...no runtime influence when the user doesn't use memory mirror ? It is a new feature, so how about like this: default y -> n? It's okay to me. But it's better to check performance impact before merge because you modified core code of memory management. Thanks, -Kame -- 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: [RFC PATCH 10/12] mm: add the buddy system interface
On 2015/06/09 19:04, Xishi Qiu wrote:
On 2015/6/9 15:12, Kamezawa Hiroyuki wrote:
On 2015/06/04 22:04, Xishi Qiu wrote:
Add the buddy system interface for address range mirroring feature.
Allocate mirrored pages in MIGRATE_MIRROR list. If there is no mirrored pages
left, use other types pages.
Signed-off-by: Xishi Qiu
---
mm/page_alloc.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d4d2066..0fb55288 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -599,6 +599,26 @@ static inline bool is_mirror_pfn(unsigned long pfn)
return false;
}
+
+static inline bool change_to_mirror(gfp_t gfp_flags, int high_zoneidx)
+{
+/*
+ * Do not alloc mirrored memory below 4G, because 0-4G is
+ * all mirrored by default, and the list is always empty.
+ */
+if (high_zoneidx < ZONE_NORMAL)
+return false;
+
+/* Alloc mirrored memory for only kernel */
+if (gfp_flags & __GFP_MIRROR)
+return true;
GFP_KERNEL itself should imply mirror, I think.
Hi Kame,
How about like this: #define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS |
__GFP_MIRROR) ?
Hm it cannot cover GFP_ATOMIC at el.
I guess, mirrored memory should be allocated if !__GFP_HIGHMEM or !__GFP_MOVABLE
thanks,
-Kame
Thanks,
-Kame
--
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 v7 00/10] tracing: 'hist' triggers
On 2015/06/09 6:31, Tom Zanussi wrote:
> This is v7 of the 'hist triggers' patchset, following feedback from
> v6.
>
> Changes from v6:
>
> This version adds a new 'sym-offset' modifier as requested by Masami.
> I implemented it as a modifier rather than using the trace option as
> suggested, in part because I wanted to keep it all self-contained and
> it seemed more consistent to just add it alongside the 'sym' modifier.
> Also, hist triggers arent't really a tracer and therefore don't
> directly tie into the option update/callback mechanism so making use
> of it isn't as simple as a normal tracer.
>
> I also changed the sort key specification to be stricter and signal an
> error if the specified sort key wasn't found (rather than defaulting
> to hitcount in those cases), also suggested by Masami. Thanks,
> Masami, for your input!
OK, here I've ran a quick test.
-
[root@localhost tracing]# perf probe __kmalloc caller=\$stack0 size
Added new event:
probe:__kmalloc (on __kmalloc with caller=$stack0 size)
You can now use it in all perf tools, such as:
perf record -e probe:__kmalloc -aR sleep 1
[root@localhost tracing]# echo
hist:keys=caller.sym-offset,size:value=hitcount:sort=size >
events/probe/__kmalloc/trigger
[root@localhost tracing]# echo 1 > events/probe/__kmalloc/enable
[root@localhost tracing]# cat events/probe/__kmalloc/hist
# trigger info:
hist:keys=caller.sym-offset,size:vals=hitcount:sort=size:size=2048 [active]
{ caller: [811e1142] shmem_initxattrs+0x92/0xe0
, size: 17 } hitcount: 14
{ caller: [81296860] load_elf_binary+0x240/0x10e0
, size: 28 } hitcount: 4
{ caller: [813ed384] security_context_to_sid_core+0x64/0x280
, size: 30 } hitcount: 84
{ caller: [813ec0cc] context_struct_to_string+0x11c/0x220
, size: 36 } hitcount: 14
{ caller: [8125bf84] alloc_fdmem+0x24/0x40
, size: 64 } hitcount: 17
{ caller: [812653cc] simple_xattr_alloc+0x2c/0x70
, size: 68 } hitcount: 14
{ caller: [a0304770] __nf_ct_ext_add_length+0x160/0x1a0 [nf_conntrack]
, size: 96 } hitcount: 6
{ caller: [81395ca7] kmem_alloc+0x77/0xf0
, size:112 } hitcount: 2
{ caller: [81416058] bio_alloc_bioset+0x248/0x330
, size:152 } hitcount: 12
{ caller: [81395ca7] kmem_alloc+0x77/0xf0
, size:384 } hitcount: 2
{ caller: [812965f6] load_elf_phdrs+0x76/0xa0
, size:392 } hitcount: 4
{ caller: [812965f6] load_elf_phdrs+0x76/0xa0
, size:504 } hitcount: 4
{ caller: [8169cbdb] sk_prot_alloc+0xcb/0x1b0
, size: 1136 } hitcount: 2
{ caller: [8125bf84] alloc_fdmem+0x24/0x40
, size: 2048 } hitcount: 17
{ caller: [812628fb] seq_buf_alloc+0x1b/0x50
, size: 3024 } hitcount: 2
{ caller: [812628fb] seq_buf_alloc+0x1b/0x50
, size: 4096 } hitcount: 35
{ caller: [81196540] tracing_map_sort_entries+0x30/0x5c0
, size: 16384 } hitcount: 1
Totals:
Hits: 234
Entries: 17
Dropped: 0
-
Looks good to me :)
-
[root@localhost tracing]# echo
hist:keys=caller.sym-offset,size:value=hitcount:sort=XXX >
events/probe/__kmalloc/trigger
-bash: echo: write error: Invalid argument
[root@localhost tracing]# echo hist:keys=caller.sym-offset,size:value=abc >
events/probe/__kmalloc/trigger
-bash: echo: write error: Invalid argument
[root@localhost tracing]# echo hist:keys=yyy > events/probe/__kmalloc/trigger
-bash: echo: write error: Invalid argument
-
Also, it seems to check parse error correctly.
I'll take a look for each patch.
Thank you,
>
> Also updated the Documentation and tracing/README to reflect the
> changes.
>
> Changes from v5:
>
> This version adds support for compound keys, along with the related
> ability to sort using primary and secondary keys. This was mentioned
> in previous versions as the last important piece that remained
> unimplemented, and is now implemented. (I didn't have time to get to
> the couple of enhancements suggested by Masami, but I expect to be
> able to add those later on top of these.)
>
> Because we now support compound keys and it's not immediately clear in
> the output exactly which fields correspond to keys, the key(s),
> compound or not, are now enclosed by curly braces.
>
> The Documentation and README have been
Re: [Cluster-devel] [PATCH] dlm: remove unnecessary error check
- Original Message - > Hi Bob, > > Bob Peterson wrote: > > - Original Message - > > > >> We don't need the redundant logic since send_message always returns 0. > >> > >> Signed-off-by: Guoqing Jiang > >> --- > >> fs/dlm/lock.c | 10 ++ > >> 1 file changed, 2 insertions(+), 8 deletions(-) > >> > >> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c > >> index 35502d4..6fc3de9 100644 > >> --- a/fs/dlm/lock.c > >> +++ b/fs/dlm/lock.c > >> @@ -3656,10 +3656,7 @@ static int send_common(struct dlm_rsb *r, struct > >> dlm_lkb *lkb, int mstype) > >> > >>send_args(r, lkb, ms); > >> > >> - error = send_message(mh, ms); > >> - if (error) > >> - goto fail; > >> - return 0; > >> + return send_message(mh, ms); > >> > >> fail: > >>remove_from_waiters(lkb, msg_reply_type(mstype)); > >> @@ -3763,10 +3760,7 @@ static int send_lookup(struct dlm_rsb *r, struct > >> dlm_lkb *lkb) > >> > >>send_args(r, lkb, ms); > >> > >> - error = send_message(mh, ms); > >> - if (error) > >> - goto fail; > >> - return 0; > >> + return send_message(mh, ms); > >> > >> fail: > >>remove_from_waiters(lkb, DLM_MSG_LOOKUP_REPLY); > >> -- > >> 1.7.12.4 > >> > > > > Hi, > > > > The patch looks okay, but if remove_from_waiters() always returns 0, > > wouldn't it be better to change the function from int to void and > > return 0 here? The advantage is that code spelunkers wouldn't need > > to back-track one more level (not to mention the instruction or two > > it might save). > > > > > Seems remove_from_waiters is not always returns 0, the return value > could be -1 or 0 which depends on _remove_from_waiters. > > BTW, I found that there are no big difference between send_common > and send_lookup, since the send_common can also be use to send > lookup message, I guess send_lookup can be removed as well. > > Thanks, > Guoqing Hi Guoqing, If remove_from_waiters can return -1, then the patch would prevent the code from calling remove_from_waiters. So the patch still doesn't look right to me. Regards, Bob Peterson Red Hat File Systems -- 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: [PATCHSET block/for-4.2/writeback] block, cgroup: make cfq charge async IOs to the appropriate blkcgs
Hello, On Tue, Jun 09, 2015 at 11:05:46AM -0400, Jeff Moyer wrote: > Yeah, I sent this email before realizing that GFP_NOWAIT would work out. > I've reviewed the rest of the series. Looks good to me! You did a nice > job splitting things up into easily reviewable pieces, so thanks for > that. Thanks a lot for reviewing the patches. :) I think it's already too late for the v4.2 merge window. I'll re-post the patches w/ your reviewed-by's added once v4.2-rc1 drops. -- tejun -- 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 00/11] ARM64 PCI hostbridge init based on ACPI
Hi Jagan, On 06/08/2015 08:05 PM, Jagan Teki wrote: On 27 May 2015 at 09:27, Hanjun Guo wrote: On 2015年05月27日 08:30, Rafael J. Wysocki wrote: On Tuesday, May 26, 2015 08:49:13 PM Hanjun Guo wrote: This patch set is introducing ARM64 PCI hostbridge init based on ACPI, which based on Jiang Liu's patch set "Consolidate ACPI PCI root common code into ACPI core": https://lkml.org/lkml/2015/5/14/98 I'll be regarding this patchset as an RFC until the one from Jiang Liu goes in. Yes, please, Jiang Liu's patch set should go in first. Apart from picking all, I have skipped x86, ia64 changes from above and Jiang Liu's series with disabling MSI, but I'm observing my arm64 board isn't booted from uefi. Do you boot with ACPI? There is no support for ACPI PCI for ARM64 in mainline, which kernel do you use? I'm suspecting pci-acpi changes were generic to specific pcie root bridge controller, but do I need to do any changes wrt pcie bridge? let me know if I miss anything here. ARM64 need special handling for IO port resources based on Jiang's patch set, we still working on it. Thanks Hanjun -- 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 7/8] cfq-iosched: fold cfq_find_alloc_queue() into cfq_get_queue()
Hey, Jeff.
On Tue, Jun 09, 2015 at 10:40:02AM -0400, Jeff Moyer wrote:
> The resulting code (introduced by the last patch, I know) is not ideal:
>
> rcu_read_lock();
> cfqg = cfq_lookup_create_cfqg(cfqd, bio_blkcg(bio));
> if (!cfqg) {
> cfqq = >oom_cfqq;
> goto out;
> }
>
> if (!is_sync) {
> if (!ioprio_valid(cic->ioprio)) {
> struct task_struct *tsk = current;
> ioprio = task_nice_ioprio(tsk);
> ioprio_class = task_nice_ioclass(tsk);
> }
> async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class,
> ioprio);
> cfqq = *async_cfqq;
> if (cfqq)
> goto out;
> }
>
> As you mentioned, we don't need to lookup the cfqg for the async queue.
> What's more is we could fallback to the oom_cfqq even if we had an
> existing async cfqq. I'm guessing you structured the code this way to
> make the error path cleaner. I don't think it's a big deal, as it
> should be a rare occurrence, so...
In this patch, the lookup seems unnecessary for the async case but the
change is required for the following changes because async queues are
moved from cfq_data to cfq_group, so we can't determine async queues
w/o looking up cfqg at all and we'll have to fall back to oom_cfqq if
cfqg lookup fails (cuz there's no system-wide async queues).
Thanks.
--
tejun
--
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 v2 1/4] x86, mwaitt: add monitorx and mwaitx instruction
On Tue, Jun 09, 2015 at 07:06:14PM +0200, Borislav Petkov wrote: > On Tue, Jun 09, 2015 at 09:44:59AM -0700, Andy Lutomirski wrote: > > [1] For those who weren't bitten by this repeatedly, modern Intel CPUs > > (at least Sandy Bridge, anyway) will, by default, detect when all > > cores are in C1 or deeper, think to themselves "wow, the OS selected > > C1 -- it must want a very deep sleep indeed", and put the whole > > package into some kind of deep sleep state. The subsequent wakeup > > takes tens of milliseconds. Doing this in udelay would be awful. > > That's a good point. Reportedly, the current MWAITX enters something > between C0 and C1 but the way I understood it, going forward, it will > enter deeper sleep states. > > So for shallow C-states, your idle enter/exit latency is low enough but > I'd guess deeper states would be a problem. > Andy, Boris, that's right. Thanks. :) If MWAITX will enter C1 and restore back repeatedly. It will impact the accuracy of delay. I will ask HW designer to check if it already has configuration to control the target power state. Thanks, Rui -- 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: [Cluster-devel] [PATCH] dlm: remove unnecessary error check
Hi Bob, Bob Peterson wrote: > - Original Message - > >> We don't need the redundant logic since send_message always returns 0. >> >> Signed-off-by: Guoqing Jiang >> --- >> fs/dlm/lock.c | 10 ++ >> 1 file changed, 2 insertions(+), 8 deletions(-) >> >> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c >> index 35502d4..6fc3de9 100644 >> --- a/fs/dlm/lock.c >> +++ b/fs/dlm/lock.c >> @@ -3656,10 +3656,7 @@ static int send_common(struct dlm_rsb *r, struct >> dlm_lkb *lkb, int mstype) >> >> send_args(r, lkb, ms); >> >> -error = send_message(mh, ms); >> -if (error) >> -goto fail; >> -return 0; >> +return send_message(mh, ms); >> >> fail: >> remove_from_waiters(lkb, msg_reply_type(mstype)); >> @@ -3763,10 +3760,7 @@ static int send_lookup(struct dlm_rsb *r, struct >> dlm_lkb *lkb) >> >> send_args(r, lkb, ms); >> >> -error = send_message(mh, ms); >> -if (error) >> -goto fail; >> -return 0; >> +return send_message(mh, ms); >> >> fail: >> remove_from_waiters(lkb, DLM_MSG_LOOKUP_REPLY); >> -- >> 1.7.12.4 >> > > Hi, > > The patch looks okay, but if remove_from_waiters() always returns 0, > wouldn't it be better to change the function from int to void and > return 0 here? The advantage is that code spelunkers wouldn't need > to back-track one more level (not to mention the instruction or two > it might save). > > Seems remove_from_waiters is not always returns 0, the return value could be -1 or 0 which depends on _remove_from_waiters. BTW, I found that there are no big difference between send_common and send_lookup, since the send_common can also be use to send lookup message, I guess send_lookup can be removed as well. Thanks, Guoqing -- 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: [ANNOUNCE] 4.0.4-rt1
On Wed, 2015-06-10 at 01:05 +0300, Pavel Vasilyev wrote: > 09.06.2015 19:45, Fernando Lopez-Lezcano пишет: > > > This is still happening, about once a day. John Dulaney help me set up a > > crash kernel dump (thanks!) so now I have a kernel core dump for this > > one, > > Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime > system? :D So? Distro kernels have all that and more, yet manage to power video games that would say "Game over, insert bucket of gold doubloons" if they had coin slots^Wchutes. There's more to the rt world than skinny little boxen, rt sumo exists. -Mike -- 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 v4] powerpc/cache: add cache flush operation for various e500
From: Tang Yuantian
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback function will flush all caches inside the current cpu.
Signed-off-by: Chenhui Zhao
Signed-off-by: Tang Yuantian
---
v4:
- line up cpu_down_flush*
v3:
- change all flush_caches to cpu_down_flush
- replace whitespace with tab
v2:
- remove some function's prefix "__"
- remove redundent CONFIG_PPC_E500MC micro
arch/powerpc/include/asm/cacheflush.h | 2 -
arch/powerpc/include/asm/cputable.h | 11 +++
arch/powerpc/kernel/asm-offsets.c | 3 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 112 ++
arch/powerpc/kernel/cputable.c| 4 ++
arch/powerpc/kernel/head_fsl_booke.S | 74
arch/powerpc/platforms/85xx/smp.c | 3 +-
7 files changed, 132 insertions(+), 77 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 30b35ff..729fde4 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -30,8 +30,6 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping)do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-extern void __flush_disable_L1(void);
-
extern void flush_icache_range(unsigned long, unsigned long);
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 6367b83..069 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -43,6 +43,13 @@ extern int machine_check_e500(struct pt_regs *regs);
extern int machine_check_e200(struct pt_regs *regs);
extern int machine_check_47x(struct pt_regs *regs);
+#if defined(CONFIG_E500)
+extern void cpu_down_flush_e500v2(void);
+extern void cpu_down_flush_e500mc(void);
+extern void cpu_down_flush_e5500(void);
+extern void cpu_down_flush_e6500(void);
+#endif
+
/* NOTE WELL: Update identify_cpu() if fields are added or removed! */
struct cpu_spec {
/* CPU is matched via (PVR & pvr_mask) == pvr_value */
@@ -59,6 +66,10 @@ struct cpu_spec {
unsigned inticache_bsize;
unsigned intdcache_bsize;
+#if defined(CONFIG_E500)
+ /* flush caches inside the current cpu */
+ void (*cpu_down_flush)(void);
+#endif
/* number of performance monitor counters */
unsigned intnum_pmcs;
enum powerpc_pmc_type pmc_type;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 0034b6b..52efca9 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -373,6 +373,9 @@ int main(void)
DEFINE(CPU_SPEC_FEATURES, offsetof(struct cpu_spec, cpu_features));
DEFINE(CPU_SPEC_SETUP, offsetof(struct cpu_spec, cpu_setup));
DEFINE(CPU_SPEC_RESTORE, offsetof(struct cpu_spec, cpu_restore));
+#if defined(CONFIG_E500)
+ DEFINE(CPU_DOWN_FLUSH, offsetof(struct cpu_spec, cpu_down_flush));
+#endif
DEFINE(pbe_address, offsetof(struct pbe, address));
DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index dddba3e..462aed9 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,11 +13,13 @@
*
*/
+#include
#include
#include
#include
#include
#include
+#include
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
@@ -233,3 +235,113 @@ _GLOBAL(__setup_cpu_e5500)
mtlrr5
blr
#endif
+
+/* flush L1 date cache, it can apply to e500v2, e500mc and e5500 */
+_GLOBAL(flush_dcache_L1)
+ mfmsr r10
+ wrteei 0
+
+ mfspr r3,SPRN_L1CFG0
+ rlwinm r5,r3,9,3 /* Extract cache block size */
+ twlgti r5,1/* Only 32 and 64 byte cache blocks
+* are currently defined.
+*/
+ li r4,32
+ subfic r6,r5,2 /* r6 = log2(1KiB / cache block size) -
+* log2(number of ways)
+*/
+ slw r5,r4,r5/* r5 = cache block size */
+
+ rlwinm r7,r3,0,0xff/* Extract number of KiB in the cache */
+ mulli r7,r7,13/* An 8-way cache will require 13
+* loads per set.
+*/
+ slw r7,r7,r6
+
+ /* save off HID0 and set DCFA */
+
RE: [PATCH] ARM: pgtable: Fix typo in the comment
Hello Steve, On Tue, June 09, 2015 5:43 PM, Steve Capper wrote: > On 9 June 2015 at 07:52, Hyuk Myeong wrote: >> This patch fix a spelling typo in the comment in pgtable-2level.h. >> > > Hi Hyuk, > >> Signed-off-by: Hyuk Myeong >> --- >> arch/arm/include/asm/pgtable-2level.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/include/asm/pgtable-2level.h >> b/arch/arm/include/asm/pgtable-2level.h >> index bfd662e..49f91be 100644 >> --- a/arch/arm/include/asm/pgtable-2level.h >> +++ b/arch/arm/include/asm/pgtable-2level.h >> @@ -66,7 +66,7 @@ >> * >> * However, when the "young" bit is cleared, we deny access to the page >> * by clearing the hardware PTE. Currently Linux does not flush the TLB >> - * for us in this case, which means the TLB will retain the transation >> + * for us in this case, which means the TLB will retain the transaction > > Don't you mean "translation" rather than "transaction"? > Cheers, Thank you for the advice I had been confused between the two because I assumed that "transaction" is not that bad in this context (as a set of the translation) Like you said, if "translation" is better here than I will send a new patch -- 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 v2] crypto: drbg - reseed often if seedsource is degraded
Changes v2:
* port the patch to current cryptodev tree plus the async seeding DRBG patches
---8<---
As required by SP800-90A, the DRBG implements are reseeding threshold.
This threshold is at 2**48 (64 bit) and 2**32 bit (32 bit) as
implemented in drbg_max_requests.
With the recently introduced changes, the DRBG is now always used as a
stdrng which is initialized very early in the boot cycle. To ensure that
sufficient entropy is present, the Jitter RNG is added to even provide
entropy at early boot time.
However, the 2nd seed source, the nonblocking pool, is usually
degraded at that time. Therefore, the DRBG is seeded with the Jitter RNG
(which I believe contains good entropy, which however is questioned by
others) and is seeded with a degradded nonblocking pool. This seed is
now used for quasi the lifetime of the system (2**48 requests is a lot).
The patch now changes the reseed threshold as follows: up until the time
the DRBG obtains a seed from a fully iniitialized nonblocking pool, the
reseeding threshold is lowered such that the DRBG is forced to reseed
itself resonably often. Once it obtains the seed from a fully
initialized nonblocking pool, the reseed threshold is set to the value
required by SP800-90A.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 12 +++-
include/crypto/drbg.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index c6cbf13..5fad297 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1088,6 +1088,9 @@ static void drbg_async_seed(struct work_struct *work)
__drbg_seed(drbg, , true);
+ if (drbg->seeded)
+ drbg->reseed_threshold = drbg_max_requests(drbg);
+
mutex_unlock(>drbg_mutex);
memzero_explicit(entropy, entropylen);
@@ -1334,7 +1337,7 @@ static int drbg_generate(struct drbg_state *drbg,
* 9.3.1 step 6 and 9 supplemented by 9.3.2 step c is implemented
* here. The spec is a bit convoluted here, we make it simpler.
*/
- if ((drbg_max_requests(drbg)) < drbg->reseed_ctr)
+ if (drbg->reseed_threshold < drbg->reseed_ctr)
drbg->seeded = false;
if (drbg->pr || !drbg->seeded) {
@@ -1478,6 +1481,12 @@ static int drbg_prepare_hrng(struct drbg_state *drbg)
drbg->jent = crypto_alloc_rng("jitterentropy_rng", 0, 0);
+ /*
+* Require frequent reseeds until the seed source is fully
+* initialized.
+*/
+ drbg->reseed_threshold = 50;
+
return err;
}
@@ -1522,6 +1531,7 @@ static int drbg_instantiate(struct drbg_state *drbg,
struct drbg_string *pers,
drbg->core = _cores[coreref];
drbg->pr = pr;
drbg->seeded = false;
+ drbg->reseed_threshold = drbg_max_requests(drbg);
ret = drbg_alloc_state(drbg);
if (ret)
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index fad6450..9756c70 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -111,6 +111,7 @@ struct drbg_state {
unsigned char *C;
/* Number of RNG requests since last reseed -- 10.1.1.1 1c) */
size_t reseed_ctr;
+ size_t reseed_threshold;
/* some memory the DRBG can use for its operation */
unsigned char *scratchpad;
void *priv_data;/* Cipher handle */
--
2.4.2
--
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: [RFC PATCH v6 25/32] perf tools: Add 'bpf.' config section to perf default config
On 2015/6/10 9:09, Alexei Starovoitov wrote: On 6/9/15 5:47 PM, Wangnan (F) wrote: On 2015/6/10 7:43, Alexei Starovoitov wrote: On 6/8/15 10:50 PM, Wang Nan wrote: perf_bpf_config() is added to parse 'bpf' section in perf config file. Following is an example: [bpf] clang-path = /llvm/bin/x86_64-linux-clang" llc-path = /llvm/bin/x86_64-linux-llc" clang-opt = "-nostdinc -isystem /llvm/lib/clang/include -I/kernel/arch/x86/include ..." llc-opt = "" a section to specify -I flags to compile prog.c is useful, but users shouldn't be populating it manually for kernel headers. How about adding a script that can figure out $(LINUXINCLUDE) automatically ? You can even invoke such flag detector from perf via something like: f = open /tmpdir/Makefile fprintf(f, "obj-y := dummy.o\n"); fprintf(f, "$(obj)/%%.o: $(src)/%%.c\n"); fprintf(f, "\t@echo -n \"$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)\" > %s\n", cachefile); snprintf(cmd, "make -s -C /lib/modules/%s/build M=%s dummy.o", uts_release, tmpdir); system(cmd); read flags from cachefile and cache it for the future. ... or as independent script that populates .perfconfig That's cool, but could I implement it later? Introducing such stuffs I think --clang-opts shouldn't be introduced without automatic flag finder. Ease of use is important. What about automatic finder failed? It is possible that user environment doesn't have kbuild directory installed, should we make it another deadend? Then these 'ease of use' design is useless for me because in embedded area usecases are always rare. I think we can hide --clang-opt from cmdline, make it reside in .perfconfig only, and pop some messages on it when failure. Most of the time users need to config only once. Still not very hard, right? also introduces a lot of trouble tasks: 1. Dependency on make and kernel build. We should search make and kbuild dir dynamically and also gives users the right to specify them by theirselves. A lot of configuration options should be appended: --make-path=/path/to/make --kbuild-dir=kernel/build/dir in cmdline and [kbuild] make_path = /path/to/make kbuild_dir = /path/to/kbuild in .perfconfig. they're not mandatory. If 'make' is not in a PATH, it's dead end. kernel build is very likely installed in /lib/modules/ 2. Selection of architectures. Although currently we want it to work only when we dynamically compile a script, I think finally we should consider cross compiling bpf objects. Then cmdline generation becomes complex. Also, --arch and [kbuild.arch] should also be introduced. that's a rare use case. This one can be added later. 3. Kernel dependency. Consider if kernel decides to change its interface... change what interface? 'make M=' ? sure. then lots of scripts will be broken. 'make M=' is unlikely to be changed. However it is possible for kernel to append more variable for specifying include, or devide $(NOSTDINC_FLAGS) $(LINUXINCLUDE) and $(EXTRA_CFLAGS) into smaller pieces. I'm not quite sure whether those make variables are part of kbuild interface. I think currently we can pop some messages to let user know how to get include dirs manually, let further patches to do it for them automatically. P.S. Have you tested your Makefile? It doesn't work for me: works as a charm: $ cat /home/ast/ff/Makefile obj-y := dummy.o $(obj)/%.o: $(src)/%.c @echo -n "$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)" > /tmp/xxx $ make -s -C /w/net-next/bld_x64 M=/home/ast/ff dummy.o $ cat /tmp/xxx -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.7/include -I../arch/x86/include -Iarch/x86/include/generated/uapi -Iarch/x86/include/generated -I../include -Iinclude -I../arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I../include/uapi -Iinclude/generated/uapi -include ../include/linux/kconfig.h Finally I made it work. dummy.c must exist on current directory. What we are talking about seems not very suit to be implemented using C. It should be implemented using a shell script: #!/usr/bin/env sh TMPDIR=`mktemp -d` cat << EOF > $TMPDIR/Makefile obj-y := dummy.o \$(obj)/%.o: \$(src)/%.c @echo -n "\$(NOSTDINC_FLAGS) \$(LINUXINCLUDE) \$(EXTRA_CFLAGS)" > $TMPDIR/cflags EOF touch $TMPDIR/dummy.c DEFAULT_KBUILD_DIR=/lib/modules/`uname -r`/build if ! test -d "$KBUILD_DIR" then KBUILD_DIR=$DEFAULT_KBUILD_DIR fi make -s -C $KBUILD_DIR M=$TMPDIR $OTHER_OPTS dummy.o 2>/dev/null cat $TMPDIR/cflags 2>/dev/null RET=$? rm -rf $TMPDIR exit $RET In this script, we can inject KBUILD_DIR and OTHER_OPTS to select another kbuild directory and "ARCH=" option. I'll embed this script in my next version. Thaknk you. -- 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] HSI: nokia-modem: use flags argument of devm_gpiod_get to set direction
On 06/08/2015 06:53 PM, Uwe Kleine-König wrote: Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Use this to simplify the driver. Furthermore this is one caller less that stops us making the flags argument to gpiod_get*() mandatory. Acked-by: Alexandre Courbot Thanks Uwe for taking care of this! -- 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 v3 0/2] Support for CEVA SATA Host controller
On Tue, Jun 09, 2015 at 02:23:48PM +0530, Suneel Garapati wrote: > Adds support for CEVA SATA Host controller found on Xilinx Zynq > Ultrascale+ MPSoC. Applied to libata/for-4.2. Thanks! -- tejun -- 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: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions
On Tue, 9 Jun 2015 21:00:58 -0500 (CDT) Christoph Lameter wrote: > On Tue, 9 Jun 2015, Andrew Morton wrote: > > > > Why do this at all? > > > > For the third time: because there are approx 200 callsites which are > > already doing it. > > Did some grepping and I did see some call sites that do this but the > majority has to do other processing as well. > > 200 call sites? Do we have that many uses of caches? Typical prod system > have ~190 caches active and the merging brings that down to half of that. I didn't try terribly hard. z:/usr/src/linux-4.1-rc7> grep -r -C1 kmem_cache_destroy . | grep "if [(]" | wc -l 158 It's a lot, anyway. > > More than half of the kmem_cache_destroy() callsites are declining that > > value by open-coding the NULL test. That's reality and we should recognize > > it. > > Well that may just indicate that we need to have a look at those > callsites and the reason there to use a special cache at all. This makes no sense. Go look at the code. drivers/staging/lustre/lustre/llite/super25.c, for example. It's all in the basic unwind/recover/exit code. > If the cache > is just something that kmalloc can provide then why create a special > cache. On the other hand if something special needs to be accomplished > then it would make sense to have special processing on kmem_cache_destroy. This has nothing to do with anything. We're talking about a basic "if I created this cache then destroy it" operation. It's a common pattern. mm/ exists to serve client code and as a lot of client code is doing this, we should move it into mm/ so as to serve client code better. -- 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] usb: dwc2: fix unnecessary USB overcurrent condition
Hi Dinh, Responding again to the proper message to add linux-usb. And also added more comments. On 5/26/2015 7:32 PM, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > For platforms that use a ULPI phy, we should enable the external VbusValid > signal instead. I don't think it should be for all ULPI phys. Though I'm not that familiar with ULPI. > > Signed-off-by: Dinh Nguyen > Cc: Gregory Herrero > Cc: Mian Yousaf Kaukab > Cc: Felipe Balbi > --- > drivers/usb/dwc2/core.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c > index e5b546f..08ffdc6 100644 > --- a/drivers/usb/dwc2/core.c > +++ b/drivers/usb/dwc2/core.c > @@ -807,6 +807,11 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool > select_phy, int irq) > if (hsotg->core_params->ts_dline > 0) > usbcfg |= GUSBCFG_TERMSELDLPULSE; > > + /* Set external VBUS indicator as needed. */ > + if (hsotg->core_params->phy_type == DWC2_PHY_TYPE_PARAM_ULPI) > + usbcfg |= (GUSBCFG_ULPI_INT_VBUS_IND | > +GUSBCFG_INDICATORPASSTHROUGH); > + I think these should all be conditional on using the external vbus, and probably also on the features themselves since it will depend on the PHY and platform how you want to set these bits. John -- 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] ACPI / init: Switch over platform to the ACPI mode later
On 06/10/2015 07:48 AM, Rafael J. Wysocki wrote: On Wednesday, June 03, 2015 11:13:57 AM Toshi Kani wrote: On Sat, 2015-05-30 at 14:21 +0200, Rafael J. Wysocki wrote: From: Rafael J. Wysocki Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()" moved the ACPI subsystem initialization, including the ACPI mode enabling, to an earlier point in the initialization sequence, to allow the timekeeping subsystem use ACPI early. Unfortunately, that resulted in boot regressions on some systems and the early ACPI initialization was moved toward its original position in the kernel initialization code by commit c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later". However, that turns out to be insufficient, as boot is still broken on the Tyan S8812 mainboard. To fix that issue, split the ACPI early initialization code into two pieces so the majority of it still located in acpi_early_init() and the part switching over the platform into the ACPI mode goes into a new function, acpi_subsystem_init(), executed at the original early ACPI initialization spot. That fixes the Tyan S8812 boot problem, but still allows ACPI tables to be loaded earlier which is useful to the EFI code in efi_enter_virtual_mode(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141 Reported-and-tested-by: Marius Tolzmann Signed-off-by: Rafael J. Wysocki Can you add comments to acpi_early_init() and acpi_subsystem_init() to clarify what ACPI features are enabled at each phase, and what dependency they have in the boot sequence? (The same goes to early_acpi_boot_init() and acpi_boot_init().) OK, update follows. --- From: Rafael J. Wysocki Subject: ACPI / init: Switch over platform to the ACPI mode later Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()" moved the ACPI subsystem initialization, including the ACPI mode enabling, to an earlier point in the initialization sequence, to allow the timekeeping subsystem use ACPI early. Unfortunately, that resulted in boot regressions on some systems and the early ACPI initialization was moved toward its original position in the kernel initialization code by commit c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later". However, that turns out to be insufficient, as boot is still broken on the Tyan S8812 mainboard. To fix that issue, split the ACPI early initialization code into two pieces so the majority of it still located in acpi_early_init() and the part switching over the platform into the ACPI mode goes into a new function, acpi_subsystem_init(), executed at the original early ACPI initialization spot. That fixes the Tyan S8812 boot problem, but still allows ACPI tables to be loaded earlier which is useful to the EFI code in efi_enter_virtual_mode(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141 Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()" Reported-and-tested-by: Marius Tolzmann Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani --- drivers/acpi/bus.c | 56 +-- include/linux/acpi.h |2 + init/main.c |1 3 files changed, 44 insertions(+), 15 deletions(-) Index: linux-pm/drivers/acpi/bus.c === --- linux-pm.orig/drivers/acpi/bus.c +++ linux-pm/drivers/acpi/bus.c @@ -470,6 +470,16 @@ static int __init acpi_bus_init_irq(void return 0; } +/** + * acpi_early_init - Initialize ACPICA and populate the ACPI namespace. + * + * The ACPI tables are accessible after this, but the handling of events has not Maybe we need to explicitly say that it's DSDT/SSDT, because static tables such as FADT and MADT are accessible in the very early stage of boot (in setup_arch()). Other than that, Reviewed-by: Hanjun Guo Thanks Hanjun -- 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: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions
On (06/09/15 20:11), Christoph Lameter wrote: > On Tue, 9 Jun 2015, Andrew Morton wrote: > > > Well I like it, even though it's going to cause a zillion little cleanup > > patches. > > > > checkpatch already has a "kfree(NULL) is safe and this check is > > probably not required" test so I guess Joe will need to get busy ;) > > > > I'll park these patches until after 4.1 is released - it's getting to > > that time... > > Why do this at all? this makes things less fragile. > I understand that kfree/kmem_cache_free can take a > null pointer but this is the destruction of a cache and it usually > requires multiple actions to clean things up and these actions have to be > properly sequenced. All other processors have to stop referencing this > cache before it can be destroyed. >I think failing well, it's not just `failing', it's a NULL pointer deref. > if someone does something strange like doing cache destruction with a > NULL pointer is valuable. > a missing check is not `something strange'. it's just happening. (a very quick google search) http://help.lockergnome.com/linux/PATCH-dlm-NULL-dereference-failure-kmem_cache_create--ftopict555436.html http://linux-kernel.2935.n7.nabble.com/PATCH-2-6-30-rc6-Remove-kmem-cache-destroy-in-s3c24xx-dma-init-td460417.html etc. -ss -- 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 v3] powerpc/cache: add cache flush operation for various e500
On Tue, 2015-06-09 at 21:00 -0500, Tang Yuantian-B29983 wrote: > Please see my replay inline. > > From: Wood Scott-B07421 > Sent: Wednesday, June 10, 2015 6:28 AM > To: Tang Yuantian-B29983 > Cc: Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; > linux-kernel@vger.kernel.org; Zhao Chenhui-B35336; Tang Yuantian > Subject: Re: [PATCH v3] powerpc/cache: add cache flush operation for > various e500 > > On Tue, 2015-06-09 at 09:53 +0800, Yuantian.Tang@freescale.comwrote: > > From: Tang Yuantian > > > > Various e500 core have different cache architecture, so they > > need different cache flush operations. Therefore, add a callback > > function cpu_flush_caches to the struct cpu_spec. The cache flush > > operation for the specific kind of e500 is selected at init time. > > The callback function will flush all caches inside the current cpu. > > > > Signed-off-by: Chenhui Zhao > > Signed-off-by: Tang Yuantian > > --- > > v3: > > - change all flush_caches to cpu_down_flush > > - replace whitespace with tab > [snip] > .cpu_setup = __setup_cpu_e500v2, > > .machine_check = machine_check_e500, > > .platform = "ppc8548", > > + .cpu_down_flush = cpu_down_flush_e500v2, > > It's still not lined up. I'm not a fan of the "line up all the =" > style, as it's a pain to maintain (and can be harder to read if the > "=" > is too far to the right), but mixing the two is worse. > > [Yuantian]: > I need more clear about this. > The only difference here is that my function puts ONE tab before "=" > and ONE white space after "="; > but the other functions in this structure use TWO tabs before "=". > Is that what you want? The existing code aligns all the "=" characters (using whatever number of tabs before "=" are required to accomplish that). Yours doesn't. -Scott -- 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: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions
On Tue, 9 Jun 2015, Andrew Morton wrote: > > Why do this at all? > > For the third time: because there are approx 200 callsites which are > already doing it. Did some grepping and I did see some call sites that do this but the majority has to do other processing as well. 200 call sites? Do we have that many uses of caches? Typical prod system have ~190 caches active and the merging brings that down to half of that. > More than half of the kmem_cache_destroy() callsites are declining that > value by open-coding the NULL test. That's reality and we should recognize > it. Well that may just indicate that we need to have a look at those callsites and the reason there to use a special cache at all. If the cache is just something that kmalloc can provide then why create a special cache. On the other hand if something special needs to be accomplished then it would make sense to have special processing on kmem_cache_destroy. -- 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 v2 2/2] TPM: remove unnecessary little endian conversion
The base pointer for the event log is allocated in the local
kernel (in prom_instantiate_sml()), therefore it is already in
the host's endian byte order and requires no conversion.
The content of the 'basep' pointer in read_log() stores the
base address of the log. This patch ensures that it is correctly
implemented.
Signed-off-by: Hon Ching(Vicky) Lo
Signed-off-by: Joy Latten
---
drivers/char/tpm/tpm_of.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
index c002d1b..62a22ce 100644
--- a/drivers/char/tpm/tpm_of.c
+++ b/drivers/char/tpm/tpm_of.c
@@ -24,7 +24,7 @@ int read_log(struct tpm_bios_log *log)
{
struct device_node *np;
const u32 *sizep;
- const __be64 *basep;
+ const u64 *basep;
if (log->bios_event_log != NULL) {
pr_err("%s: ERROR - Eventlog already initialized\n", __func__);
@@ -63,7 +63,7 @@ int read_log(struct tpm_bios_log *log)
log->bios_event_log_end = log->bios_event_log + *sizep;
- memcpy(log->bios_event_log, __va(be64_to_cpup(basep)), *sizep);
+ memcpy(log->bios_event_log, __va(*basep), *sizep);
return 0;
--
1.7.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 v2 1/2] vTPM: support little endian guests
This patch makes the code endianness independent. We defined a
macro do_endian_conversion to apply endianness to raw integers
in the event entries so that they will be displayed properly.
tpm_binary_bios_measurements_show() is modified for the display.
Signed-off-by: Hon Ching(Vicky) Lo
Signed-off-by: Joy Latten
---
drivers/char/tpm/tpm_eventlog.c | 81 --
drivers/char/tpm/tpm_eventlog.h |6 +++
2 files changed, 65 insertions(+), 22 deletions(-)
diff --git a/drivers/char/tpm/tpm_eventlog.c b/drivers/char/tpm/tpm_eventlog.c
index 3a56a13..8689957 100644
--- a/drivers/char/tpm/tpm_eventlog.c
+++ b/drivers/char/tpm/tpm_eventlog.c
@@ -76,15 +76,25 @@ static void *tpm_bios_measurements_start(struct seq_file
*m, loff_t *pos)
void *addr = log->bios_event_log;
void *limit = log->bios_event_log_end;
struct tcpa_event *event;
+ u32 converted_event_size;
+ u32 converted_event_type;
+
/* read over *pos measurements */
for (i = 0; i < *pos; i++) {
event = addr;
+ converted_event_size =
+ do_endian_conversion(event->event_size);
+ converted_event_type =
+ do_endian_conversion(event->event_type);
+
if ((addr + sizeof(struct tcpa_event)) < limit) {
- if (event->event_type == 0 && event->event_size == 0)
+ if ((converted_event_type == 0) &&
+ (converted_event_size == 0))
return NULL;
- addr += sizeof(struct tcpa_event) + event->event_size;
+ addr += (sizeof(struct tcpa_event) +
+converted_event_size);
}
}
@@ -94,8 +104,12 @@ static void *tpm_bios_measurements_start(struct seq_file
*m, loff_t *pos)
event = addr;
- if ((event->event_type == 0 && event->event_size == 0) ||
- ((addr + sizeof(struct tcpa_event) + event->event_size) >= limit))
+ converted_event_size = do_endian_conversion(event->event_size);
+ converted_event_type = do_endian_conversion(event->event_type);
+
+ if (((converted_event_type == 0) && (converted_event_size == 0))
+ || ((addr + sizeof(struct tcpa_event) + converted_event_size)
+ >= limit))
return NULL;
return addr;
@@ -107,8 +121,12 @@ static void *tpm_bios_measurements_next(struct seq_file
*m, void *v,
struct tcpa_event *event = v;
struct tpm_bios_log *log = m->private;
void *limit = log->bios_event_log_end;
+ u32 converted_event_size;
+ u32 converted_event_type;
- v += sizeof(struct tcpa_event) + event->event_size;
+ converted_event_size = do_endian_conversion(event->event_size);
+
+ v += sizeof(struct tcpa_event) + converted_event_size;
/* now check if current entry is valid */
if ((v + sizeof(struct tcpa_event)) >= limit)
@@ -116,11 +134,11 @@ static void *tpm_bios_measurements_next(struct seq_file
*m, void *v,
event = v;
- if (event->event_type == 0 && event->event_size == 0)
- return NULL;
+ converted_event_size = do_endian_conversion(event->event_size);
+ converted_event_type = do_endian_conversion(event->event_type);
- if ((event->event_type == 0 && event->event_size == 0) ||
- ((v + sizeof(struct tcpa_event) + event->event_size) >= limit))
+ if (((converted_event_type == 0) && (converted_event_size == 0)) ||
+ ((v + sizeof(struct tcpa_event) + converted_event_size) >= limit))
return NULL;
(*pos)++;
@@ -140,7 +158,7 @@ static int get_event_name(char *dest, struct tcpa_event
*event,
int i, n_len = 0, d_len = 0;
struct tcpa_pc_event *pc_event;
- switch(event->event_type) {
+ switch (do_endian_conversion(event->event_type)) {
case PREBOOT:
case POST_CODE:
case UNUSED:
@@ -156,14 +174,17 @@ static int get_event_name(char *dest, struct tcpa_event
*event,
case NONHOST_CODE:
case NONHOST_CONFIG:
case NONHOST_INFO:
- name = tcpa_event_type_strings[event->event_type];
+ name =
+ tcpa_event_type_strings[do_endian_conversion
+ (event->event_type)];
n_len = strlen(name);
break;
case SEPARATOR:
case ACTION:
- if (MAX_TEXT_EVENT > event->event_size) {
+ if (MAX_TEXT_EVENT >
+ do_endian_conversion(event->event_size)) {
name = event_entry;
- n_len = event->event_size;
+ n_len = do_endian_conversion(event->event_size);
}
break;
case EVENT_TAG:
@@ -171,7 +192,7 @@ static int
Re: [42/73] rtc: delete non-required instances of include
On Tue, Jun 9, 2015 at 3:49 AM, Alexandre Belloni wrote: > On 08/06/2015 at 17:06:34 -0400, Paul Gortmaker wrote : >> > I've contemplated applying that patch but I'm not sure it is actually a >> > good idea because those 46 drivers are using a variant of module_driver >> > which actually uses __init and __exit. After your patch it is still >> > working simply because init.h gets included that way: >> >> Firstly, I am kind of curious why an 18 month old patch is getting >> replied to now. That aside, this interdependence between module.h and >> init.h was reconsidered and you can see the resolution solution here: >> >> https://lkml.kernel.org/r/1433276168-21550-1-git-send-email-paul.gortma...@windriver.com >> >> To summarize what is said there, yes - you can ignore the one line >> removals for now. We will revisit them after the above is merged. >> > > I've taken the RTC subsystem maintainership and I've been sorting the > 2372 patches left in patchwork down to 126 and yours was one of these. > > Seeing your answer, I think my question was legitimate. I'll be happy to > take your revised patch once ready. Yes, it was a legit (and correct) spotting ; just some months late. :) I'll be sure to make sure you are CC'd on any updates. And thanks for taking over maintainership of the rtc subsystem. I'll go out on a limb here and guess that the original rtc driver author ; that idiot never imagined it would become a subsystem, else he'd thank you as well. Paul. -- > > -- > Alexandre Belloni, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-arch" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions
On Tue, 9 Jun 2015 20:11:25 -0500 (CDT) Christoph Lameter wrote: > On Tue, 9 Jun 2015, Andrew Morton wrote: > > > Well I like it, even though it's going to cause a zillion little cleanup > > patches. > > > > checkpatch already has a "kfree(NULL) is safe and this check is > > probably not required" test so I guess Joe will need to get busy ;) > > > > I'll park these patches until after 4.1 is released - it's getting to > > that time... > > Why do this at all? For the third time: because there are approx 200 callsites which are already doing it. > I understand that kfree/kmem_cache_free can take a > null pointer but this is the destruction of a cache and it usually > requires multiple actions to clean things up and these actions have to be > properly sequenced. All other processors have to stop referencing this > cache before it can be destroyed. I think failing if someone does > something strange like doing cache destruction with a NULL pointer is > valuable. More than half of the kmem_cache_destroy() callsites are declining that value by open-coding the NULL test. That's reality and we should recognize it. -- 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] USB: uvc: add support for the Microsoft Surface Pro 3 Cameras
> Is this needed ? Looking at the patch your cameras are UVC-compliant > and > should thus be picked by the uvcvideo driver without any change to > the code. The cameras are UVC-compliant but are not recognized by the uvc driver. The patch forces the uvc driver to pick up the camera if present. -- 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] procfs: Always expose /proc//map_files/ and make it readable
On Tuesday 06/09 at 14:13 -0700, Andrew Morton wrote: > On Mon, 8 Jun 2015 20:39:33 -0700 Calvin Owens wrote: > > > Currently, /proc//map_files/ is restricted to CAP_SYS_ADMIN, and > > is only exposed if CONFIG_CHECKPOINT_RESTORE is set. > > > > This interface very useful because it allows userspace to stat() > > deleted files that are still mapped by some process, which enables a > > much quicker and more accurate answer to the question "How much disk > > space is being consumed by files that are deleted but still mapped?" > > than is currently possible. > > Why is that information useful? > > I could perhaps think of some use for "How much disk space is being > consumed by files that are deleted but still open", but to count the > mmapped-then-unlinked files while excluding the opened-then-unlinked > files seems damned peculiar. Let's phrase the question a bit more generically: "How much disk space is being consumed by files that have been unlinked, but are still referenced by some process?" There are two pieces to this problem: 1) Unlinked files that are still open (whether mapped or not) 2) Unlinked files that are not open, but are still mapped You can track down everything in (1) using /proc//fd/*, and you can use stat() to figure out how much space they're using. But directly measuring how much space (2) consumes is actually not currently possible from userspace: there's no way to stat() the files. You can get the inode number from /proc//maps, but that still doesn't get you anywhere because it's been unlinked from the filesystem. So I'm not looking to measure (2) and exclude (1): I'm looking to have a way to directly measure (2) at all. The reason I say "directly", and I say "quicker and more accurate" in the original message, is that there is a very ugly way to answer this question right now: you sum up the number of blocks used by every file on the disk and subtract it from what statfs() tells you. This obviously stinks, and becomes untenable once your filesystem is large enough. > IOW, this changelog failed to explain the value of the patch. Bad > changelog! Please sell it to us. Preferably with real-world use > cases. The real-world use case is catching long-lived processes that leak references to temporary files and waste space on the disk. When such processes leak file-backed mappings, this wasted space is especially difficult to detect until it gets out of hand. The map_files/ interface eliminates this difficulty. I've included a little test program at the end of this file to illustrate what I'm getting at here. It creates a file at /tmp/DELETEDFILE: calvinowens@Haydn:~$ gcc test.c calvinowens@Haydn:~$ ./a.out & [1] 5832 Holding mapping at 0x7fe74d1ea000 calvinowens@Haydn:~$ lsof -p `pgrep a.out` COMMAND PIDUSER FD TYPE DEVICE SIZE/OFFNODE NAME a.out 5832 calvinowens cwdDIR 254,1 4096 3413033 /home/calvinowens a.out 5832 calvinowens rtdDIR 254,1 4096 2 / a.out 5832 calvinowens txtREG 254,1 7512 3408268 /home/calvinowens/a.out a.out 5832 calvinowens memREG 254,1 1729984 4456767 /lib/x86_64-linux-gnu/libc-2.19.so a.out 5832 calvinowens memREG 254,1 140928 4456619 /lib/x86_64-linux-gnu/ld-2.19.so a.out 5832 calvinowens memREG 0,3232768 184946 /tmp/DELETEDFILE a.out 5832 calvinowens0u CHR 136,2 0t0 5 /dev/pts/2 a.out 5832 calvinowens1u CHR 136,2 0t0 5 /dev/pts/2 a.out 5832 calvinowens2u CHR 136,2 0t0 5 /dev/pts/2 calvinowens@Haydn:~$ killall a.out [1]+ Terminated ./a.out calvinowens@Haydn:~$ gcc -DDO_UNLINK test.c calvinowens@Haydn:~$ ./a.out & [1] 5842 Holding mapping at 0x7fec8ae63000 calvinowens@Haydn:~$ lsof -p `pgrep a.out` COMMAND PIDUSER FD TYPE DEVICE SIZE/OFFNODE NAME a.out 5842 calvinowens cwdDIR 254,1 4096 3413033 /home/calvinowens a.out 5842 calvinowens rtdDIR 254,1 4096 2 / a.out 5842 calvinowens txtREG 254,1 7640 3408268 /home/calvinowens/a.out a.out 5842 calvinowens memREG 254,1 1729984 4456767 /lib/x86_64-linux-gnu/libc-2.19.so a.out 5842 calvinowens memREG 254,1 140928 4456619 /lib/x86_64-linux-gnu/ld-2.19.so a.out 5842 calvinowens DELREG 0,32 184946 /tmp/DELETEDFILE a.out 5842 calvinowens0u CHR 136,2 0t0 5 /dev/pts/2 a.out 5842 calvinowens1u CHR 136,2 0t0 5 /dev/pts/2 a.out 5842 calvinowens2u CHR 136,2 0t0 5 /dev/pts/2 Notice the gap under "SIZE/OFF" in the 2nd output? This is because lsof has no possible way to actually determine the leaked file's size. That's
Re: [RFC PATCH v6 32/32] perf record: Add LLVM options for compiling BPF scripts
On 6/9/15 5:17 PM, Wangnan (F) wrote: Could you please give me some URL to LLVM git repositories so I can track your work on it? traffic on llvm/clang is very heavy. probably as much as lkml. you can subscribe to llvmweekly instead. In the future I'll cc you on new things in that area. -- 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 v2 1/3] Input: export LEDs as class devices in sysfs
On Wed, Jun 10, 2015 at 02:32:32AM +0200, Samuel Thibault wrote: > Hello, > > Thanks for the modified version. This all seems to be working as > expected with multiple keyboards. Excellent. Let's give Pavel and Pali chance to test it out and let's get it in 4.2. Thanks. -- Dmitry -- 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] USB: uvc: add support for the Microsoft Surface Pro 3 Cameras
Hi Dennis,
Thank you for the patch.
On Tuesday 09 June 2015 18:09:06 Dennis Chen wrote:
> Add support for the Microsoft Surface Pro 3 Cameras.
Is this needed ? Looking at the patch your cameras are UVC-compliant and
should thus be picked by the uvcvideo driver without any change to the code.
> Signed-off-by: Dennis Chen
> ---
> drivers/media/usb/uvc/uvc_driver.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 5970dd6..ec5a407 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2538,6 +2538,22 @@ static struct usb_device_id uvc_ids[] = {
> .bInterfaceSubClass = 1,
> .bInterfaceProtocol = 0,
> .driver_info = UVC_QUIRK_FORCE_Y8 },
> + /*Microsoft Surface Pro 3 Front Camera*/
> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> + | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x045e,
> + .idProduct= 0x07be,
> + .bInterfaceClass = USB_CLASS_VIDEO,
> + .bInterfaceSubClass = 1,
> + .bInterfaceProtocol = 1 },
> + /* Microsoft Surface Pro 3 Rear */
> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> + | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x045e,
> + .idProduct= 0x07bf,
> + .bInterfaceClass = USB_CLASS_VIDEO,
> + .bInterfaceSubClass = 1,
> + .bInterfaceProtocol = 1 },
> /* Generic USB Video Class */
> { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, 0) },
> {}
--
Regards,
Laurent Pinchart
--
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 v2] [x86/kvm] emulate.c: Fix comppilation warning
Rajat Jain writes:
> Fix the following warning:
>
> arch/x86/kvm/emulate.c: In function '__do_insn_fetch_bytes':
> arch/x86/kvm/emulate.c:814:47: warning: 'linear' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> arch/x86/kvm/emulate.c:793:16: note: 'linear' was declared here
Is this recent gcc behavior ? If yes, please mention that in the commit
message.
Please follow convention for the subject line and fix the typo -
"KVM: emulate: Fix compilation warning"
Thanks,
Bandan
> Signed-off-by: Rajat Jain
> Signed-off-by: Rajat Jain
> ---
> v2: Fix the wrong email address.
>
> arch/x86/kvm/emulate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index 630bcb0..f06e0ca 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -790,7 +790,7 @@ static int __do_insn_fetch_bytes(struct x86_emulate_ctxt
> *ctxt, int op_size)
> {
> int rc;
> unsigned size, max_size;
> - unsigned long linear;
> + unsigned long linear = 0;
> int cur_size = ctxt->fetch.end - ctxt->fetch.data;
> struct segmented_address addr = { .seg = VCPU_SREG_CS,
> .ea = ctxt->eip + cur_size };
--
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: [RFC][PATCH 0/5] do not dereference NULL pools in pools' destroy() functions
On Tue, 9 Jun 2015, Andrew Morton wrote: > Well I like it, even though it's going to cause a zillion little cleanup > patches. > > checkpatch already has a "kfree(NULL) is safe and this check is > probably not required" test so I guess Joe will need to get busy ;) > > I'll park these patches until after 4.1 is released - it's getting to > that time... Why do this at all? I understand that kfree/kmem_cache_free can take a null pointer but this is the destruction of a cache and it usually requires multiple actions to clean things up and these actions have to be properly sequenced. All other processors have to stop referencing this cache before it can be destroyed. I think failing if someone does something strange like doing cache destruction with a NULL pointer is valuable. -- 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: [RFC PATCH v6 25/32] perf tools: Add 'bpf.' config section to perf default config
On 6/9/15 5:47 PM, Wangnan (F) wrote: On 2015/6/10 7:43, Alexei Starovoitov wrote: On 6/8/15 10:50 PM, Wang Nan wrote: perf_bpf_config() is added to parse 'bpf' section in perf config file. Following is an example: [bpf] clang-path = /llvm/bin/x86_64-linux-clang" llc-path = /llvm/bin/x86_64-linux-llc" clang-opt = "-nostdinc -isystem /llvm/lib/clang/include -I/kernel/arch/x86/include ..." llc-opt = "" a section to specify -I flags to compile prog.c is useful, but users shouldn't be populating it manually for kernel headers. How about adding a script that can figure out $(LINUXINCLUDE) automatically ? You can even invoke such flag detector from perf via something like: f = open /tmpdir/Makefile fprintf(f, "obj-y := dummy.o\n"); fprintf(f, "$(obj)/%%.o: $(src)/%%.c\n"); fprintf(f, "\t@echo -n \"$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)\" > %s\n", cachefile); snprintf(cmd, "make -s -C /lib/modules/%s/build M=%s dummy.o", uts_release, tmpdir); system(cmd); read flags from cachefile and cache it for the future. ... or as independent script that populates .perfconfig That's cool, but could I implement it later? Introducing such stuffs I think --clang-opts shouldn't be introduced without automatic flag finder. Ease of use is important. also introduces a lot of trouble tasks: 1. Dependency on make and kernel build. We should search make and kbuild dir dynamically and also gives users the right to specify them by theirselves. A lot of configuration options should be appended: --make-path=/path/to/make --kbuild-dir=kernel/build/dir in cmdline and [kbuild] make_path = /path/to/make kbuild_dir = /path/to/kbuild in .perfconfig. they're not mandatory. If 'make' is not in a PATH, it's dead end. kernel build is very likely installed in /lib/modules/ 2. Selection of architectures. Although currently we want it to work only when we dynamically compile a script, I think finally we should consider cross compiling bpf objects. Then cmdline generation becomes complex. Also, --arch and [kbuild.arch] should also be introduced. that's a rare use case. This one can be added later. 3. Kernel dependency. Consider if kernel decides to change its interface... change what interface? 'make M=' ? sure. then lots of scripts will be broken. I think currently we can pop some messages to let user know how to get include dirs manually, let further patches to do it for them automatically. P.S. Have you tested your Makefile? It doesn't work for me: works as a charm: $ cat /home/ast/ff/Makefile obj-y := dummy.o $(obj)/%.o: $(src)/%.c @echo -n "$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)" > /tmp/xxx $ make -s -C /w/net-next/bld_x64 M=/home/ast/ff dummy.o $ cat /tmp/xxx -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.7/include -I../arch/x86/include -Iarch/x86/include/generated/uapi -Iarch/x86/include/generated -I../include -Iinclude -I../arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I../include/uapi -Iinclude/generated/uapi -include ../include/linux/kconfig.h -- 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] seccomp: add ptrace options for suspend/resume
On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
wrote:
> This patch is the first step in enabling checkpoint/restore of processes
> with seccomp enabled.
>
> One of the things CRIU does while dumping tasks is inject code into them
> via ptrace to collect information that is only available to the process
> itself. However, if we are in a seccomp mode where these processes are
> prohibited from making these syscalls, then what CRIU does kills the task.
>
> This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
> a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
> filters to disable (and re-enable) seccomp filters for another task so that
> they can be successfully dumped (and restored). We restrict the set of
> processes that can disable seccomp through ptrace because although today
> ptrace can be used to bypass seccomp, there is some discussion of closing
> this loophole in the future and we would like this patch to not depend on
> that behavior and be future proofed for when it is removed.
>
> Note that seccomp can be suspended before any filters are actually
> installed; this behavior is useful on criu restore, so that we can suspend
> seccomp, restore the filters, unmap our restore code from the restored
> process' address space, and then resume the task by detaching and have the
> filters resumed as well.
>
> v2 changes:
>
> * require that the tracer have no seccomp filters installed
> * drop TIF_NOTSC manipulation from the patch
> * change from ptrace command to a ptrace option and use this ptrace option
> as the flag to check. This means that as soon as the tracer
> detaches/dies, seccomp is re-enabled and as a corrollary that one can not
> disable seccomp across PTRACE_ATTACHs.
>
> v3 changes:
>
> * get rid of various #ifdefs everywhere
> * report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
> used
>
> v4 changes:
>
> * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
> directly
>
> Signed-off-by: Tycho Andersen
> CC: Kees Cook
> CC: Andy Lutomirski
> CC: Will Drewry
> CC: Roland McGrath
> CC: Oleg Nesterov
> CC: Pavel Emelyanov
> CC: Serge E. Hallyn
> ---
> include/linux/ptrace.h | 1 +
> include/uapi/linux/ptrace.h | 6 --
> kernel/ptrace.c | 9 +
> kernel/seccomp.c| 8
> 4 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
> index 987a73a..061265f 100644
> --- a/include/linux/ptrace.h
> +++ b/include/linux/ptrace.h
> @@ -34,6 +34,7 @@
> #define PT_TRACE_SECCOMP PT_EVENT_FLAG(PTRACE_EVENT_SECCOMP)
>
> #define PT_EXITKILL(PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
> +#define PT_SUSPEND_SECCOMP (PTRACE_O_SUSPEND_SECCOMP <<
> PT_OPT_FLAG_SHIFT)
>
> /* single stepping state bits (used on ARM and PA-RISC) */
> #define PT_SINGLESTEP_BIT 31
> diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> index cf1019e..a7a6979 100644
> --- a/include/uapi/linux/ptrace.h
> +++ b/include/uapi/linux/ptrace.h
> @@ -89,9 +89,11 @@ struct ptrace_peeksiginfo_args {
> #define PTRACE_O_TRACESECCOMP (1 << PTRACE_EVENT_SECCOMP)
>
> /* eventless options */
> -#define PTRACE_O_EXITKILL (1 << 20)
> +#define PTRACE_O_EXITKILL (1 << 20)
> +#define PTRACE_O_SUSPEND_SECCOMP (1 << 21)
>
> -#define PTRACE_O_MASK (0x00ff | PTRACE_O_EXITKILL)
> +#define PTRACE_O_MASK (\
> + 0x00ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
>
> #include
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index c8e0e05..11fa460 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child,
> unsigned long data)
> if (data & ~(unsigned long)PTRACE_O_MASK)
> return -EINVAL;
>
> + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> + !config_enabled(CONFIG_SECCOMP))
> + return -EINVAL;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
I tend to think that we should also require that current not be using
seccomp. Otherwise, in principle, there's a seccomp bypass for
privileged-but-seccomped programs. In any event, CRIU isn't going to
work well if you run the restorer under seccomp, since it'll start
nesting in a manner that probably isn't desirable.
> + }
> +
> /* Avoid intermediate state when all opts are cleared */
> flags = child->ptrace;
> flags &= ~(PTRACE_O_MASK << PT_OPT_FLAG_SHIFT);
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 980fd26..645e42d 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
> {
> int mode = current->seccomp.mode;
>
> +
Re: [PATCH] USB: uvc: add support for the Microsoft Surface Pro 3 Cameras
Add support for the Microsoft Surface Pro 3 Cameras.
Signed-off-by: Dennis Chen
---
drivers/media/usb/uvc/uvc_driver.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 5970dd6..ec5a407 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2538,6 +2538,22 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_FORCE_Y8 },
+ /*Microsoft Surface Pro 3 Front Camera*/
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x045e,
+ .idProduct= 0x07be,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 1 },
+ /* Microsoft Surface Pro 3 Rear */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x045e,
+ .idProduct= 0x07bf,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 1 },
/* Generic USB Video Class */
{ USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, 0) },
{}
--
2.4.2
--
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: [RFC 0/4] enable migration of non-LRU pages
2015-06-10 오전 9:08에 Minchan Kim 이(가) 쓴 글: Hello Gioh, On Tue, Jun 02, 2015 at 04:27:40PM +0900, Gioh Kim wrote: Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver and zram are non-movable pages. So I reported Minchan Kim, the maintainer of zram, and he made the internal compaction logic of zram. And I made the internal compaction of GPU driver. They reduced some fragmentation but they are not enough effective. They are activated by its own interface, /sys, so they are not cooperative with kernel compaction. If there is too much fragmentation and kernel starts to compaction, zram and GPU driver cannot work with the kernel compaction. The first this patch adds a generic isolate/migrate/putback callbacks for page address-space. The zram and GPU, and any other modules can register its own migration method. The kernel compaction can call the registered migration when it works. Therefore all page in the system can be migrated at once. The 2nd the generic migration callbacks are applied into balloon driver. My gpu driver code is not open so I apply generic migration into balloon to show how it works. I've tested it with qemu enabled by kvm like followings: - turn on Ubuntu 14.04 with 1G memory on qemu. - do kernel building - after several seconds check more than 512MB is used with free command - command "balloon 512" in qemu monitor - check hundreds MB of pages are migrated Next kernel compaction code can call generic migration callbacks instead of balloon driver interface. Finally calling migration of balloon driver is removed. I didn't hava a time to review but it surely will help using zram with CMA as well as fragmentation of the system memory via making zram objects movable. I know you are busy. I hope you make time for review. If it lands on mainline, I will work for zram object migration. Thanks! -- 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: [RFC] module: add per-module params lock
On Mon, Jun 8, 2015 at 5:13 PM, Rusty Russell wrote: > Dan Streetman writes: >> On Thu, Jun 4, 2015 at 8:42 PM, Rusty Russell wrote: >>> Dan Streetman writes: I sent this as part of a patch series a few days ago, which I was asked to break up, so I'm sending only this patch as a RFC now, until I work out the details of the zswap patch that needs this. I'd like to get comments on this early, since it changes the way module param locking is done. >>> >>> OK, it's not insane, but I'm not entirely convinced. >>> >>> 1) The difference between blocking sysfs for read vs write is mainly >>>documentation. In theory, it allows a rwsem, though in practice it's >>>not been a bottleneck to now. >> >> The sysfs block/unblock calls could remain the same, but the downside >> there is a module can't block more than 1 of its params. It seemed to >> me like the per-param r/w block functions were adding unnecessary >> restrictions, since we're not using a rwsem for each individual param. >> If the param lock is changed to a rwsem in the future, it won't be >> hard to also change all callers. Or, we could change it to a resem >> now. But as you said, kernel param locking isn't really a contended >> lock. >> >>> >>> 2) Implicit is bad: implying the module rather than the parameter is >>>weird >> >> Well implying it enforces only blocking your own module params; should >> module A be blocking and accessing module B's params? Isn't requiring >> each module to pass THIS_MODULE unnecessary, at least in the vast >> majority of cases? There is still __kernel_param_lock(module) that >> can be used if it really is necessary anywhere to block some other >> module's params. Or, I can change it to require passing THIS_MODULE >> if you think that's a better api. > > It's weird to do anything other than lock the actual parameter you're > talking about. Nobody actually seems to want multi param locks (and if > they try it they'll quickly discover it deadlocks). > >>> , and skips the BUG_ON() check which was there before. >> >> those made absolutely no sense to me; why in the world is it necessary >> to BUG() simply because the param permissions don't match r or w? At >> *most* that deserves a WARN_ON() but more likely a pr_warn() is >> appropriate. And even then, who cares? Does it actually cause any >> harm? No. Especially since the underlying lock isn't a rwsem. But >> even if it *was* a rwsem, it still wouldn't hurt anything. > > Because you're locking something that can't change. I really want that > not to happen: I'd make it BUILD_BUG_ON() if I could. Ah, ok. I dug in there and I see the perm field isn't actually changeable from sysfs, it's only the initial setting; so chmod will only change the sysfs file perm, not the kernel_param.perm field that the block_sysfs macros check. If that's the case and perm *really* should never change, why not just make it const and use BUILD_BUG_ON()? I'll send a patch... > > You're confusing the API (which explicitly DOESN'T talk about locking, > just blocking sysfs access), and the implementation. For the majority > of users, the API is more important. > > If you really dislike the API (and it's such a minor one), perhaps it's > better to expose the lock explicitly: I got to this point only because I was getting deadlocked when loading a module from a param callback, so the API was really secondary to me; I don't hate the API; and BUILD_BUG_ON seems a lot better. If the global mutex -> per module mutex seems ok, I can send reduce the patch to only do that without changing the API. -- 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: [RFC PATCH v6 25/32] perf tools: Add 'bpf.' config section to perf default config
On 2015/6/10 7:43, Alexei Starovoitov wrote: On 6/8/15 10:50 PM, Wang Nan wrote: perf_bpf_config() is added to parse 'bpf' section in perf config file. Following is an example: [bpf] clang-path = /llvm/bin/x86_64-linux-clang" llc-path = /llvm/bin/x86_64-linux-llc" clang-opt = "-nostdinc -isystem /llvm/lib/clang/include -I/kernel/arch/x86/include ..." llc-opt = "" a section to specify -I flags to compile prog.c is useful, but users shouldn't be populating it manually for kernel headers. How about adding a script that can figure out $(LINUXINCLUDE) automatically ? You can even invoke such flag detector from perf via something like: f = open /tmpdir/Makefile fprintf(f, "obj-y := dummy.o\n"); fprintf(f, "$(obj)/%%.o: $(src)/%%.c\n"); fprintf(f, "\t@echo -n \"$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)\" > %s\n", cachefile); snprintf(cmd, "make -s -C /lib/modules/%s/build M=%s dummy.o", uts_release, tmpdir); system(cmd); read flags from cachefile and cache it for the future. ... or as independent script that populates .perfconfig That's cool, but could I implement it later? Introducing such stuffs also introduces a lot of trouble tasks: 1. Dependency on make and kernel build. We should search make and kbuild dir dynamically and also gives users the right to specify them by theirselves. A lot of configuration options should be appended: --make-path=/path/to/make --kbuild-dir=kernel/build/dir in cmdline and [kbuild] make_path = /path/to/make kbuild_dir = /path/to/kbuild in .perfconfig. 2. Selection of architectures. Although currently we want it to work only when we dynamically compile a script, I think finally we should consider cross compiling bpf objects. Then cmdline generation becomes complex. Also, --arch and [kbuild.arch] should also be introduced. 3. Kernel dependency. Consider if kernel decides to change its interface... I think currently we can pop some messages to let user know how to get include dirs manually, let further patches to do it for them automatically. P.S. Have you tested your Makefile? It doesn't work for me: # cat ./Makefile obj-y := dummy.o $(obj)/%.o: $(src)/%.c @echo -n "$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)" > # make -s -C kernel/build/dir M=`pwd` dummy.o make[2]: *** No rule to make target `dummy.o'. Stop. make[1]: *** [sub-make] Error 2 make: *** [__sub-make] Error 2 Thank you. -- 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] USB: uvc: add support for the Microsoft Surface Pro 3 Cameras
Hi Dennis, -ENOPATCH ? On Tuesday 09 June 2015 12:53:34 Dennis Chen wrote: > -- Regards, Laurent Pinchart -- 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 v4] seccomp: add ptrace options for suspend/resume
This patch is the first step in enabling checkpoint/restore of processes
with seccomp enabled.
One of the things CRIU does while dumping tasks is inject code into them
via ptrace to collect information that is only available to the process
itself. However, if we are in a seccomp mode where these processes are
prohibited from making these syscalls, then what CRIU does kills the task.
This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
filters to disable (and re-enable) seccomp filters for another task so that
they can be successfully dumped (and restored). We restrict the set of
processes that can disable seccomp through ptrace because although today
ptrace can be used to bypass seccomp, there is some discussion of closing
this loophole in the future and we would like this patch to not depend on
that behavior and be future proofed for when it is removed.
Note that seccomp can be suspended before any filters are actually
installed; this behavior is useful on criu restore, so that we can suspend
seccomp, restore the filters, unmap our restore code from the restored
process' address space, and then resume the task by detaching and have the
filters resumed as well.
v2 changes:
* require that the tracer have no seccomp filters installed
* drop TIF_NOTSC manipulation from the patch
* change from ptrace command to a ptrace option and use this ptrace option
as the flag to check. This means that as soon as the tracer
detaches/dies, seccomp is re-enabled and as a corrollary that one can not
disable seccomp across PTRACE_ATTACHs.
v3 changes:
* get rid of various #ifdefs everywhere
* report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
used
v4 changes:
* get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
directly
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Will Drewry
CC: Roland McGrath
CC: Oleg Nesterov
CC: Pavel Emelyanov
CC: Serge E. Hallyn
---
include/linux/ptrace.h | 1 +
include/uapi/linux/ptrace.h | 6 --
kernel/ptrace.c | 9 +
kernel/seccomp.c| 8
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 987a73a..061265f 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -34,6 +34,7 @@
#define PT_TRACE_SECCOMP PT_EVENT_FLAG(PTRACE_EVENT_SECCOMP)
#define PT_EXITKILL(PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
+#define PT_SUSPEND_SECCOMP (PTRACE_O_SUSPEND_SECCOMP << PT_OPT_FLAG_SHIFT)
/* single stepping state bits (used on ARM and PA-RISC) */
#define PT_SINGLESTEP_BIT 31
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index cf1019e..a7a6979 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -89,9 +89,11 @@ struct ptrace_peeksiginfo_args {
#define PTRACE_O_TRACESECCOMP (1 << PTRACE_EVENT_SECCOMP)
/* eventless options */
-#define PTRACE_O_EXITKILL (1 << 20)
+#define PTRACE_O_EXITKILL (1 << 20)
+#define PTRACE_O_SUSPEND_SECCOMP (1 << 21)
-#define PTRACE_O_MASK (0x00ff | PTRACE_O_EXITKILL)
+#define PTRACE_O_MASK (\
+ 0x00ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
#include
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index c8e0e05..11fa460 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child,
unsigned long data)
if (data & ~(unsigned long)PTRACE_O_MASK)
return -EINVAL;
+ if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
+ if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
+ !config_enabled(CONFIG_SECCOMP))
+ return -EINVAL;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ }
+
/* Avoid intermediate state when all opts are cleared */
flags = child->ptrace;
flags &= ~(PTRACE_O_MASK << PT_OPT_FLAG_SHIFT);
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 980fd26..645e42d 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
{
int mode = current->seccomp.mode;
+ if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
+ unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
+ return;
+
if (mode == 0)
return;
else if (mode == SECCOMP_MODE_STRICT)
@@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
int this_syscall = sd ? sd->nr :
syscall_get_nr(current, task_pt_regs(current));
+ if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
+ unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
+ return SECCOMP_PHASE1_OK;
+
switch (mode) {
Re: [PATCH v2 1/3] Input: export LEDs as class devices in sysfs
Hello, Thanks for the modified version. This all seems to be working as expected with multiple keyboards. Samuel -- 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: clock driver
Michael, I have rewritten the driver to use CCF. It will be sent for review when ready. I have some questions, hoping you can shed some light on them. Q1: What does of_clk_add_provider do? I read the code and comment. It registers a clock provider for a node. How is it used after registration? Q2: What do you suggest to name multiple clocks on PCIe (FPGA) cards? I will have multiple cards with multiple clock chips on each. The clock driver can handle clocks on each chip. Is it recommended to create unique names by the driver? Is there any example to follow? Q3: Is there a guideline or an API to create sub folder under debugfs "clk"? Thanks a lot. York -- 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] scatterlist: use sg_phys()
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Dan Williams
> Sent: Tuesday, June 09, 2015 10:27 AM
> Subject: [PATCH 1/2] scatterlist: use sg_phys()
>
...
> diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
> index ed7ba8a11822..dcb3c594d626 100644
> --- a/arch/microblaze/kernel/dma.c
> +++ b/arch/microblaze/kernel/dma.c
> @@ -61,7 +61,7 @@ static int dma_direct_map_sg(struct device *dev, struct
> scatterlist *sgl,
> /* FIXME this part of code is untested */
> for_each_sg(sgl, sg, nents, i) {
> sg->dma_address = sg_phys(sg);
> - __dma_sync(page_to_phys(sg_page(sg)) + sg->offset,
> + __dma_sync(sg_phys(sg),
> sg->length, direction);
> }
That one ends up with weird indentation.
[PATCH v2] [x86/kvm] emulate.c: Fix comppilation warning
Fix the following warning:
arch/x86/kvm/emulate.c: In function '__do_insn_fetch_bytes':
arch/x86/kvm/emulate.c:814:47: warning: 'linear' may be used uninitialized in
this function [-Wmaybe-uninitialized]
arch/x86/kvm/emulate.c:793:16: note: 'linear' was declared here
Signed-off-by: Rajat Jain
Signed-off-by: Rajat Jain
---
v2: Fix the wrong email address.
arch/x86/kvm/emulate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 630bcb0..f06e0ca 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -790,7 +790,7 @@ static int __do_insn_fetch_bytes(struct x86_emulate_ctxt
*ctxt, int op_size)
{
int rc;
unsigned size, max_size;
- unsigned long linear;
+ unsigned long linear = 0;
int cur_size = ctxt->fetch.end - ctxt->fetch.data;
struct segmented_address addr = { .seg = VCPU_SREG_CS,
.ea = ctxt->eip + cur_size };
--
2.2.0.rc0.207.ga3a616c
--
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] [x86/kvm] emulate.c: Fix comppilation warning
Fix the following warning:
arch/x86/kvm/emulate.c: In function '__do_insn_fetch_bytes':
arch/x86/kvm/emulate.c:814:47: warning: 'linear' may be used uninitialized in
this function [-Wmaybe-uninitialized]
arch/x86/kvm/emulate.c:793:16: note: 'linear' was declared here
Signed-off-by: Rajat Jain
Signed-off-by: Rajat Jain
---
arch/x86/kvm/emulate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 630bcb0..f06e0ca 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -790,7 +790,7 @@ static int __do_insn_fetch_bytes(struct x86_emulate_ctxt
*ctxt, int op_size)
{
int rc;
unsigned size, max_size;
- unsigned long linear;
+ unsigned long linear = 0;
int cur_size = ctxt->fetch.end - ctxt->fetch.data;
struct segmented_address addr = { .seg = VCPU_SREG_CS,
.ea = ctxt->eip + cur_size };
--
2.2.0.rc0.207.ga3a616c
--
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: linux-next: build failure after merge of the drm tree
Hi Alex,
On Tue, 9 Jun 2015 14:02:21 + "Deucher, Alexander"
wrote:
>
> > -Original Message-
> > From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> > Sent: Tuesday, June 09, 2015 9:43 AM
> > To: Dave Airlie
> > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher,
> > Alexander
> > Subject: linux-next: build failure after merge of the drm tree
> >
> > Hi Dave,
> >
> > After merging the drm tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
> > 'gfx_v7_0_cp_gfx_resume':
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: error: 'BUF_SWAP_32BIT'
> > undeclared (first use in this function)
> > tmp |= BUF_SWAP_32BIT;
> > ^
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: note: each undeclared
> > identifier is reported only once for each function it appears in
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
> > 'gfx_v7_0_cp_compute_resume':
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3398:41: error:
> > 'BUF_SWAP_32BIT' undeclared (first use in this function)
> >mqd->queue_state.cp_hqd_pq_control |= BUF_SWAP_32BIT;
> > ^
> > drivers/gpu/drm/amd/amdgpu/cik_sdma.c: In function
> > 'cik_sdma_gfx_resume':
> > drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: error:
> > 'SDMA_RB_SWAP_ENABLE' undeclared (first use in this function)
> >rb_cntl |= SDMA_RB_SWAP_ENABLE |
> > SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
> > ^
> > drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: note: each undeclared
> > identifier is reported only once for each function it appears in
> > drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:36: error:
> > 'SDMA_RPTR_WRITEBACK_SWAP_ENABLE' undeclared (first use in this
> > function)
> >rb_cntl |= SDMA_RB_SWAP_ENABLE |
> > SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
> > ^
> >
> > Caused by commit a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts").
> >
>
> Should be fixed with this patch. Sorry for the breakage.
I will apply this as a fix to the drm tree merge today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpBCSXAVQQ3h.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH v6 24/32] perf record: Compile scriptlets if pass '.c' to --event
On 6/9/15 5:06 PM, Wangnan (F) wrote:
On 2015/6/10 5:48, Alexei Starovoitov wrote:
On 6/8/15 10:50 PM, Wang Nan wrote:
+struct bpf_param bpf_param = {
+.clang_path = "clang",
+.llc_path = "llc",
+.clang_opt = "",
+.llc_opt = "",
+};
the defaults are ok-ish, but llc is never in PATH.
So most likely it won't work out of the box.
I think the cleanest option is too wait a little bit
until we finish clang integration.
(hopefully few more days)
we've quite been busy on llvm side
and I'm excited to announce that BPF backend finally
graduated from experimental.
So now anyone can just pull the latest llvm and
bpf will be present by default.
No more cmake -DLLVM_EXPERIMENTAL...
Once clang integration is complete. One can pull
upsteam llvm and clang and just use 'clang -O2 -c -march=bpf file.c'
Good news, so llc part should be removed.
Next version I'd like to use following config options:
[llvm]
clang-bpf-cmd-template = "$CLANG_EXEC $CLANG_OPTIONS -c
$CLANG_SOURCE -emit-llvm -O2 -o - | /path/to/llc -march=bpf
-filetype=obj -o -"
clang-path = "/path/to/clang"
clang-opt = ""
yes. that's better.
--
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] drivercore: Fix unregistration path of platform devices
On Tue, Jun 9, 2015 at 4:00 AM, Grant Likely wrote: > On Mon, 8 Jun 2015 22:09:13 +0200 > , Ricardo Ribalda Delgado wrote: [...] >> >> > Greg, please drop Ricardo's series. It isn't correct and it will cause >> > breakage. >> >> The series can be kept, only >> >> patch "of/platform: Use platform_device interface" >> >> needs to be reverted. > > No, it's better to drop the whole series. There are still issues and it > will conflict with merging the bugfix for v4.1. > Multiple platforms stopped booting in next-20150609 as discovered by kernelci.org[1], and was bisected down to commit b6d2233f2916 (of/platform: Use platform_device interface). I'll leave you guys to sort out whether that patch or the whole series should be reverted, but I can confirm that reverting that patch on top of next-20150609 gets things booting again. Kevin [1] http://kernelci.org/boot/all/job/next/kernel/next-20150609/ -- 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: [RFC PATCH v6 32/32] perf record: Add LLVM options for compiling BPF scripts
On 2015/6/10 8:02, Alexei Starovoitov wrote: On 6/8/15 10:50 PM, Wang Nan wrote: Although previous patch allows setting BPF compiler related options in perfconfig, on some ad-hoc situation it still requires passing options through cmdline. This patch introduces 4 options to 'perf record' for this propose: --clang-path, --clang-opt, --llc-path and --llc-opt. looks good. I hope only --clang will be used from time to time. Right. Please see another mail I posted. I'd like to generate command using command template instead of printf() in next version. Today, indeed, --llc* are needed too. With template, --llc can be removed now. btw, our experimental libbpfprog.so (which is clang and llvm libs compiled into single .so with C api for compiling .c into bpf): $ ls -lh libbpfprog.so -rw-r--r-- 1 ast ast 31M Jun 9 16:49 libbpfprog.so not tiny, but I think we should be able to include it into perf, then perf will only have build dependencies on llvm instead of run-time dependencies. We'll release this lib as soon as it's a bit more stable. Could you please give me some URL to LLVM git repositories so I can track your work on it? Thank you. -- 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/1] net: fs_enet: Disable NETIF_F_SG feature for Freescale MPC5121
From: Alexander Popov Date: Wed, 10 Jun 2015 02:57:42 +0300 > skb_copy_from_linear_data() which doesn't work well for non-linear sk_buff: The correct fix is to use an SKB copy routine which can handle non-linear data. -- 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: [RFC PATCH v6 24/32] perf record: Compile scriptlets if pass '.c' to --event
On 2015/6/10 5:48, Alexei Starovoitov wrote:
On 6/8/15 10:50 PM, Wang Nan wrote:
+struct bpf_param bpf_param = {
+.clang_path = "clang",
+.llc_path = "llc",
+.clang_opt = "",
+.llc_opt = "",
+};
the defaults are ok-ish, but llc is never in PATH.
So most likely it won't work out of the box.
I think the cleanest option is too wait a little bit
until we finish clang integration.
(hopefully few more days)
we've quite been busy on llvm side
and I'm excited to announce that BPF backend finally
graduated from experimental.
So now anyone can just pull the latest llvm and
bpf will be present by default.
No more cmake -DLLVM_EXPERIMENTAL...
Once clang integration is complete. One can pull
upsteam llvm and clang and just use 'clang -O2 -c -march=bpf file.c'
Good news, so llc part should be removed.
Next version I'd like to use following config options:
[llvm]
clang-bpf-cmd-template = "$CLANG_EXEC $CLANG_OPTIONS -c
$CLANG_SOURCE -emit-llvm -O2 -o - | /path/to/llc -march=bpf
-filetype=obj -o -"
clang-path = "/path/to/clang"
clang-opt = ""
And the default template should be:
$CLANG_EXEC $CLANG_OPTIONS -c "$CLANG_SOURCE" -emit-llvm -O2 -o -
Then with environment variable tricks we make it work with popen.
By this way we can get rid of llc in perf side, and make it work even
before clang
integration is complete.
Thank you.
+err = WEXITSTATUS(pclose(file));
+if (err || read_sz <= 0) {
+err = -EINVAL;
+pr_err("Error:\tsomething went wrong when compiling %s\n",
+ filename);
+pr_err("Hint:\tTry manually run following command and
check:\n");
+pr_err(" # " CMD_FMT "\n\n",
+ clang_path, bpf_param.clang_opt, filename,
+ llc_path, bpf_param.llc_opt, "/dev/null");
not terribly informative hint.
I think would be good to point to some readme or at least mention
that only the latest clang/llvm support bpf.
Either svn/git trunk or upcoming 3.7
May be a link to llvm.org?
--
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/
