On Thursday, August 28, 2014 10:22:29 AM Jiang Liu wrote:
> Now all code in processor_core.c is APIC ID related, so rename it as
> apic_id.c. Later IOAPIC ID related code will be added into apic_id.c.
Actually, I'm not sure about this one.
Renames like this make it difficult to backport things in
[linux-scsi dropped, this is not a scsi or uas problem.]
On 7 Sep 2014, n...@esperi.org.uk stated:
> And... now it works, at least well enough to get a device file. So it's
> not the disk that's at fault: it's the no-name hub! (Which is, I think,
> USB ID 2109:0811 -- at least two instances of thi
Quoting Abel Vesa (2014-09-07 04:47:13)
> For a while now, I've started studying the power aware scheduling problem.
> And like many other rookies out there I took all the lkml mails related
> and read them all (well, almost all) and I saw that there are some
> debating on the implementation.I even
I think the problem is, when a gendisk is detached, its request queue
is not put in bypass mode
cause when it is re-attached, code tries to put it out of bypass mode,
hence the warning.
So either of these should work, I have not tested it, just coded it up.
diff --git a/block/blk-sysfs.c b/block/
On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
> On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
> > On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
> > > On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
> > > > On Thu, Sep 04, 2014 at 10:47:2
For VMAs that don't want write notifications, PTEs created for read
faults have their write bit set. If the read fault happens after
VM_SOFTDIRTY is cleared, then the PTE's softdirty bit will remain
clear after subsequent writes.
Here's a simple code snippet to demonstrate the bug:
char* m = mm
Hello,
This patchset contains the following six bdi related cleanup patches.
Each patch should be fairly self-explanatory.
0001-block-bdi-an-active-gendisk-always-has-a-request_que.patch
0002-bdi-remove-unused-stuff.patch
0003-bdi-remove-bdi-wb_lock-locking-around-bdi-dev-cleari.patch
0004-bd
Canceling of bdi->wb.dwork is currently a bit mushy.
bdi_wb_shutdown() performs cancel_delayed_work_sync() at the end after
shutting down and flushing the delayed_work and bdi_destroy() tries
yet again after bdi_unregister().
bdi->wb.dwork is queued only after checking BDI_registered while
holding
A block_device may be attached to different gendisks and thus
different bdis over time. bdev_inode_switch_bdi() is used to switch
the associated bdi. The function assumes that the inode could be
dirty and transfers it between bdis if so. This is a bit nasty in
that it reaches into bdi internals.
bdi_destroy() has code to transfer the remaining dirty inodes to the
default_backing_dev_info; however, given the shutdown sequence, it
isn't clear how such condition would happen. Also, it isn't a full
solution as the transferred inodes stlil point to the bdi which is
being destroyed. Operations
bdev_get_queue() returns the request_queue associated with the
specified block_device. blk_get_backing_dev_info() makes use of
bdev_get_queue() to determine the associated bdi given a block_device.
All the callers of bdev_get_queue() including
blk_get_backing_dev_info() assume that bdev_get_queue
Two flags and one bdi_writeback field are no longer used. Remove
them.
Signed-off-by: Tejun Heo
---
include/linux/backing-dev.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index e488e94..2103a7f 100644
--- a/include/linux/backi
The only places where NULL test on bdi->dev is used are
bdi_[un]register(). The functions can't be called in parallel anyway
and there's no point in protecting bdi->dev clearing with a lock.
Remove bdi->wb_lock grabbing around bdi->dev clearing and move it
after device_unregister() call so that bd
From: "John W. Linville"
Date: Fri, 5 Sep 2014 11:04:53 -0400
> Please pull this batch of fixes intended for the 3.17 stream...
>
> For the mac80211 bits, Johannes says:
>
> "Here are a few fixes for mac80211. One has been discussed for a while
> and adds a terminating NUL-byte to the alpha2 se
From: Beniamino Galvani
Date: Sat, 6 Sep 2014 00:28:23 +0200
> The mdio-sun4i driver automatically selects REGULATOR and
> REGULATOR_FIXED_VOLTAGE because it uses the regulator API. But a
> driver selecting a subsystem increases the chance of generating
> circular Kconfig dependencies, especiall
blkcg->id is a unique id given to each blkcg; however, the
cgroup_subsys_state which each blkcg embeds already has ->serial_nr
which can be used for the same purpose. Drop blkcg->id and replace
its uses with blkcg->css.serial_nr. Rename cfq_cgroup->blkcg_id to
->blkcg_serial_nr and @id in check_b
I'm confused why storing 0x0102 would be a problem. I think gcc does that even
on other cpus.
More atomicity can't hurt, can it?
On September 7, 2014 4:00:19 PM PDT, "Paul E. McKenney"
wrote:
>On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
>> On Sun, 2014-09-07 at 09:21 -070
On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote:
> I'm confused why storing 0x0102 would be a problem. I think gcc does that
> even on other cpus.
>
> More atomicity can't hurt, can it?
I must defer to James for any additional details on why PARISC systems
don't provide atomicity
For a short while there, this week was really nice and calm, but that
was mostly because the "linux-foundation.org" entry fell off the DNS
universe, and my mailbox got very quiet for a few hours. The rest of
the week looked pretty normal.
"Pretty normal" isn't bad, though, and I'm not complaining
How many PARISC systems do we have that actually do real work on Linux?
On September 7, 2014 4:36:55 PM PDT, "Paul E. McKenney"
wrote:
>On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote:
>> I'm confused why storing 0x0102 would be a problem. I think gcc does
>that even on other cpu
1) Fix skb leak in mac802154, from Martin Townsend.
2) Use select not depends on NF_NAT for NFT_NAT, from Pablo Neira Ayuso.
3) Fix union initializer bogosity in vxlan, from Gerhard Stenzel.
4) Fix RX checksum configuration in stmmac driver, from Giuseppe
CAVALLARO.
5) Fix TSO with non-acce
percpu_counter is scheduled to grow @gfp support to allow atomic
initialization. This patch makes percpu_counters_lock irq-safe so
that it can be safely used from atomic contexts.
Signed-off-by: Tejun Heo
---
lib/percpu_counter.c | 16 ++--
1 file changed, 10 insertions(+), 6 dele
Applied to percpu/for-3.18.
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/
Hi Jean,
On Tue, 2 Sep 2014 09:54:55 +0200 Jean Delvare wrote:
>
> On Mon, 01 Sep 2014 08:49:36 -0700, Guenter Roeck wrote:
> > On 09/01/2014 05:28 AM, Mark Brown wrote:
> > > Today's linux-next merge of the jdelvare-hwmon tree got a conflict with
> > > Linus'
> > > tree which appeared to be due
Hello, Linus.
Two patches are to add PCI IDs for ICH9 and all others are device
specific fixes. Nothing too interesting.
Thanks.
The following changes since commit 2a13772a144d2956a7fedd18685921d0a9b8b783:
libata: widen Crucial M550 blacklist matching (2014-08-18 17:40:09 -0400)
are availab
Hello,
One patch to fix a failure path in the alloc path. The bug is
dangerous but probably not too likely to actually trigger in the wild
given that there hasn't been any report yet. The other two are low
impact fixes.
Thanks.
The following changes since commit c9d26423e56ce1ab4d786f92aebecf8
Hello, Linus.
Up until now, cgroup has allowed any character including '\n' in
cgroup names; unfortunately, as '\n' is used as the row delimiter in
/proc/$PID/cgroup, '\n' in a cgroup name makes the content of the file
ambiguous to parse. This pull request includes Alban's patch to
disallow '\n'
Hello,
This patchset includes the following three patches improving
percpu-refcount.
0001-percpu-refcount-improve-WARN-messages.patch
0002-percpu-refcount-implement-percpu_ref_set_killed.patch
0003-percpu-refcount-make-percpu_ref-based-on-longs-inste.patch
The patchset is on top of percpu/for
percpu_ref's WARN messages can be a lot more helpful by indicating
who's the culprit. Make them report the release function that the
offending percpu-refcount is associated with. This should make it a
lot easier to track down the reported invalid refcnting operations.
Signed-off-by: Tejun Heo
C
percpu_ref is currently based on ints and the number of refs it can
cover is (1 << 31). This makes it impossible to use a percpu_ref to
count memory objects or pages on 64bit machines as it may overflow.
This forces those users to somehow aggregate the references before
contributing to the percpu_
With the recent addition of percpu_ref_reinit(), percpu_ref now can be
used as a persistent switch which can be turned on and off repeatedly
where turning off maps to killing the ref and waiting for it to drain;
however, there currently isn't a way to initialize a percpu_ref in its
off (killed and
Yes please Arnd, I'm still out for 1.5 week, so it would be great if you take
that through your tree with my ack. Thanks.
Robert
PS: I know, top-posting is madness, but I'm really limited by technology right
now.
- Mail d'origine -
De: Arnd Bergmann
À: Robert Jarzmik
Cc: Haojian Zhua
Fyi: i386 up -- problem introduced in rc3.
CC arch/x86/pci/irq.o
arch/x86/pci/irq.c: In function 'pirq_disable_irq':
arch/x86/pci/irq.c:1259:2: error: implicit declaration of function
'mp_should_keep_irq' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
m
Centralize redundant print messages and references to sensor names via macros.
Change msleep time from 10ms to 20ms in order to address checkpatch.pl warning:
"msleep < 20ms can sleep for up to 20ms."
Refactor redundant sensor initialization logic into two functions
(_init_sensor_w1,
_init_senso
On Thu, Aug 28, 2014 at 01:52:57PM -0700, Dave Jiang wrote:
> The following series contains various fixes and cleanup for NTB. It also
> adds the split BAR support on Haswell platform and a hardware errata
> workaround in order to allow interrupts to function during bi-directional
> traffic under s
> -Original Message-
> From: Kweh, Hock Leong
> Sent: Saturday, August 30, 2014 11:48 AM
> To: David Miller
> Cc: peppe.cavall...@st.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ong, Boon Leong; Rayagond K
> Subject: RE: [PATCH 1/4] net: stmmac: enhance to support multiple
(adds CC)
On Sun, 2014-09-07 at 22:25 -0400, Pete Clements wrote:
> Fyi: i386 up -- problem introduced in rc3.
>
> CC arch/x86/pci/irq.o
> arch/x86/pci/irq.c: In function 'pirq_disable_irq':
> arch/x86/pci/irq.c:1259:2: error: implicit declaration of function
> 'mp_should_keep_irq' [-We
On Sun, Sep 7, 2014 at 6:20 PM, Tejun Heo wrote:
>
> While this is a userland visible
> behavior change, given the craziness of allowing '\n' and its
> implications, I believe the change is justified.
Tejun, absolutely nothing "justifies" things if they break. Not "bad
design",
On Thu, Aug 28, 2014 at 01:53:29PM -0700, Dave Jiang wrote:
> A hardware errata causes the NTB to hang when heavy bi-directional traffic
> in addition to the usage of BAR0/1 (where the registers reside, including
> the doorbell registers to trigger interrupts).
>
> This workaround is only availabl
On 09/07/14 20:12, Mike Galbraith wrote:
> (adds CC)
>
> On Sun, 2014-09-07 at 22:25 -0400, Pete Clements wrote:
>> Fyi: i386 up -- problem introduced in rc3.
>>
>> CC arch/x86/pci/irq.o
>> arch/x86/pci/irq.c: In function 'pirq_disable_irq':
>> arch/x86/pci/irq.c:1259:2: error: implicit d
Hi,
On Sun, Sep 07, 2014 at 11:38:30AM +0800, Huang Ying wrote:
> Only one bit is read in check_valid_map, holding a lock to do that
> doesn't help anything except decreasing performance.
>
> Signed-off-by: Huang, Ying
> ---
>
> v2: Fixed a build warning.
>
> ---
> fs/f2fs/gc.c |3 ---
>
I2C_CLKDIV register descripted in the previous version of
RK3x chip manual is incorrect. Plus 1 is required.
The correct formula:
- T(SCL_HIGH) = T(PCLK) * (CLKDIVH + 1) * 8
- T(SCL_LOW) = T(PCLK) * (CLKDIVL + 1) * 8
- (SCL Divsor) = 8 * ((CLKDIVL + 1) + (CLKDIVH + 1))
- SCL = PCLK / (CLK Divsor)
It removes the owner field updation of driver structure.
It will be automatically updated by module_platform_driver()
Signed-off-by: Varka Bhadram
---
drivers/net/ethernet/ti/cpmac.c|1 -
drivers/net/ethernet/ti/cpsw-phy-sel.c |1 -
drivers/net/ethernet/ti/cpsw.c |1 -
Addy,
On Sun, Sep 7, 2014 at 8:38 PM, Addy Ke wrote:
> I2C_CLKDIV register descripted in the previous version of
> RK3x chip manual is incorrect. Plus 1 is required.
>
> The correct formula:
> - T(SCL_HIGH) = T(PCLK) * (CLKDIVH + 1) * 8
> - T(SCL_LOW) = T(PCLK) * (CLKDIVL + 1) * 8
> - (SCL Divsor
Hi,
Thank you for the report.
Could you share a little bit more information about the file accessing
f2fs_llseek?
E.g., file size, file offset, file allocation information, or dump of that file.
Thanks,
On Sun, Sep 07, 2014 at 10:20:44PM +0300, Tommi Rantala wrote:
> 2014-09-07 22:14 GMT+03:00 T
On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote:
> On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote:
>> > Don't we have phy_power_on()
>> > for that ? It looks like you could just as well do this from
>> > phy_power_on() ?
>>
>> No, unfortunately keeping these calibration settings
Hi Dave,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/i915/intel_display.c: In function 'intel_crtc_cursor_set_obj':
drivers/gpu/drm/i915/intel_display.c:8302:24: error: 'dev_priv' undeclared
(first use in this function)
intel_ru
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit a4bf214ffc72
("drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to
haswell_crtc_disable()") from Linus' tree and commit 575f7ab754c4
("drm/i915: Pass intel_crtc to intel
On 6 September 2014 04:17, Stephen Boyd wrote:
> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
> new file mode 100644
> index ..aa8eb97144b6
> --- /dev/null
> +++ b/drivers/cpufreq/qcom-cpufreq.c
> @@ -0,0 +1,199 @@
> +/* Copyright (c) 2014, The Linux Fo
Hello, Linus.
On Sun, Sep 07, 2014 at 08:17:11PM -0700, Linus Torvalds wrote:
> In other words, I'll happily pull this, but your excuses for it are
> wrong-headed. There is no "crazyness justifies this". That's crap. But
> the argument of "nobody does this, so let's fix it before anybody
> _starts
Hi all,
Today's linux-next merge of the integrity tree got a conflict in
fs/nfsd/vfs.c between commit 9b638b816081 ("NFSD: Put file after
ima_file_check fail in nfsd_open()") from the nfsd tree and commit
e8442e203c25 ("ima: pass 'opened' flag to identify newly created
files") from the integrity t
On 09/03/2014 05:50 PM, Chen Gang wrote:
> Need include it for irq_of_parse_and_map(), the related error with
> allmodconfig under microblaze:
>
> drivers/usb/host/ehci-xilinx-of.c: In function ‘ehci_hcd_xilinx_of_probe’:
> drivers/usb/host/ehci-xilinx-of.c:156:2: error: implicit declaration o
* Alexei Starovoitov wrote:
> > I don't think the speed up of the llvm submission is a good
> > argument, this sounds to me similar to the "please apply this
> > patch that reserves this new netlink family in
> > include/linux/netlink.h, I promise this new subsystem will be
> > submitted soo
From: Ingo Molnar
Date: Mon, 8 Sep 2014 07:23:29 +0200
>
> * Alexei Starovoitov wrote:
>
>> > I don't think the speed up of the llvm submission is a good
>> > argument, this sounds to me similar to the "please apply this
>> > patch that reserves this new netlink family in
>> > include/linux
On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
> On 09/07/2014 03:04 PM, James Bottomley wrote:
> > On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
> >> On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
> >>> On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrot
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
> How many PARISC systems do we have that actually do real work on Linux?
I'd be very surprised if this problem didn't exist on all alignment
requiring architectures, like PPC and Sparc as well. I know it would be
very convenient if all the
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm64/include/asm/kvm_host.h between commit 656473003bc7 ("KVM:
forward declare structs in kvm_types.h") from the kvm tree and commit
6951e48bff0b ("KVM: ARM/arm64: fix non-const declaration of function
returning const") f
On Sat, Sep 06, 2014 at 07:12:26PM +0200, Frederic Weisbecker wrote:
> On Sat, Sep 06, 2014 at 05:45:56PM +0200, Peter Zijlstra wrote:
> > On Sat, Sep 06, 2014 at 03:35:15PM +0200, Frederic Weisbecker wrote:
> > > You have a script that does that arch/*/include/asm/Kbuild edit for you
> > > right?
On Sun, Sep 07, 2014 at 09:42:36PM +0530, Anand Moon wrote:
> If a header file happens to be included twice, the compiler will process
> its contents twice. This is very likely to cause an error, e.g. when the
> compiler sees the same structure definition twice. Even if it does not,
> it will certa
Hi dt bindings maintainers (and others interested in device-tree bindings),
I would like to get this included in your tree. Do you think there is
still something I could improve/change in order to get this accepted?
Or do you think I should address this to someone else?
Some DS13
On Sun, Sep 7, 2014 at 10:28 PM, David Miller wrote:
> From: Ingo Molnar
> Date: Mon, 8 Sep 2014 07:23:29 +0200
>
>>
>> * Alexei Starovoitov wrote:
>>
>>> > I don't think the speed up of the llvm submission is a good
>>> > argument, this sounds to me similar to the "please apply this
>>> > patch
* David Miller wrote:
> From: Ingo Molnar
> Date: Mon, 8 Sep 2014 07:23:29 +0200
>
> >
> > * Alexei Starovoitov wrote:
> >
> >> > I don't think the speed up of the llvm submission is a
> >> > good argument, this sounds to me similar to the "please
> >> > apply this patch that reserves thi
Your From: line does not contain a real name and does not match your
Signed-off-by line, please check your e-mail client settings.
On 2014-09-07 at 20:28:25 +0200, anicoara wrote:
No changelog text? Please add a short notice, describing why this change
is done.
> Signed-off-by: Adrian Nicoara
Your From: line does not contain a real name and does not match your
Signed-off-by line, please check your e-mail client settings.
On 2014-09-07 at 20:25:35 +0200, anicoara wrote:
> Signed-off-by: Adrian Nicoara
No changelog text? Please add a short notice, describing why this change
is done.
Commit-ID: eb1b4af0a64ac7bb0ee36f579c1c7cefcbc3ac2c
Gitweb: http://git.kernel.org/tip/eb1b4af0a64ac7bb0ee36f579c1c7cefcbc3ac2c
Author: Rik van Riel
AuthorDate: Fri, 15 Aug 2014 16:05:38 -0400
Committer: Ingo Molnar
CommitDate: Mon, 8 Sep 2014 08:17:02 +0200
sched, time: Atomically incr
Commit-ID: e78c3496790ee8a36522a838b59b388e8a709e65
Gitweb: http://git.kernel.org/tip/e78c3496790ee8a36522a838b59b388e8a709e65
Author: Rik van Riel
AuthorDate: Sat, 16 Aug 2014 13:40:10 -0400
Committer: Ingo Molnar
CommitDate: Mon, 8 Sep 2014 08:17:01 +0200
time, signal: Protect resour
Commit-ID: 90ed9cbe765ad358b3151a12b8bf889a3cbcd573
Gitweb: http://git.kernel.org/tip/90ed9cbe765ad358b3151a12b8bf889a3cbcd573
Author: Rik van Riel
AuthorDate: Fri, 15 Aug 2014 16:05:36 -0400
Committer: Ingo Molnar
CommitDate: Mon, 8 Sep 2014 08:17:00 +0200
exit: Always reap resource s
Hi all,
Today's linux-next merge of the percpu tree got a conflict in
fs/ext4/super.c between commit eb68d0e2fc5a ("ext4: track extent status
tree shrinker delay statictics") from the ext4 tree and commit
908c7f1949cb ("percpu_counter: add @gfp to percpu_counter_init()") from
the percpu tree.
I f
Your From: line does not contain a real name and does not match your
Signed-off-by line, please check your e-mail client settings.
On 2014-09-07 at 20:24:03 +0200, anicoara wrote:
> Signed-off-by: Adrian Nicoara
No changelog text? Please add a short notice, describing why this change
is done.
The macro "REGMAP_ALLOW_WRITE_DEBUGFS" can be used to enable write
support on the registers file in the debugfs. The mode of the file is
fixed to 0400 so it is not possible to write the file ever.
This patch fixes the mode by setting it to the correct value depending
on the macro.
Cc: Dimitris Pa
Your From: line does not contain a real name and does not match your
Signed-off-by line, please check your e-mail client settings.
On 2014-09-07 at 20:21:41 +0200, anicoara wrote:
Changelog text is missing. Please add a short notice, describing why
this change is done.
> Signed-off-by: Adrian N
Hello Alessandro,
On Mon, Aug 18, 2014 at 10:34 AM, Javier Martinez Canillas
wrote:
> This series add support for the Real Time clock present in
> the Maxim 77802 Power Managment IC. Previously, the series
> was part of a bigger one [0] that aimed to add support for
> all the devices in the max77
Hello Mike,
On Mon, Aug 18, 2014 at 10:32 AM, Javier Martinez Canillas
wrote:
> This series add support for the clocks present in the Maxim
> 77802 Power Managment IC. Previously, the series was part
> of a bigger one [0] that aimed to add support for all the
> devices in the max77802 PMIC. But n
Hello Krzysztof,
Sorry for the late response, I was on holidays and slowly catching up on email.
On 08/28/2014 11:21 AM, Krzysztof Kozlowski wrote:
> On pon, 2014-08-18 at 10:34 +0200, Javier Martinez Canillas wrote:
>> The max77686 mfd driver adds a regmap IRQ chip which creates an
>> IRQ domain
On 7 Sep 2014, at 03:30, Mark Charlebois wrote:
> On Sat, Sep 6, 2014 at 7:16 AM, Arnd Bergmann wrote:
>>
>> On Friday 05 September 2014 16:23:14 beh...@converseincode.com wrote:
>>> + * Copyright (C) 2012 Mark Charlebois
>>> + */
>>> +
>>> +/*
>>> + * EABI routines
>>
>> Does EABI specify th
On Fri, Sep 5, 2014 at 11:50 AM, Johannes Berg
wrote:
> From: Johannes Berg
>
> Many devices run firmware and/or complex hardware, and most of that
> can have bugs. When it misbehaves, however, it is often much harder
> to debug than software running on the host.
>
Very nice concept IMO :)
[...
On Sat, Sep 06, 2014 at 11:44:32PM +0200, Piotr Karbowski wrote:
> Hi,
>
> Starting with kernel 3.15 the 'exe' symlink under /proc// acts diffrent
> than it used to in all the pre-3.15 kernels.
>
> The usecase:
>
> run /root/testbin (app that just sleeps)
> cp /root/testbin /root/testbin.new
> m
Current copying serves purpose of initializing flush req's pdu,
so don't do that if init_flush_rq is implemented.
Signed-off-by: Ming Lei
---
block/blk-mq.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 1daef32..113d58d 100644
It is reasonable to allocate flush req in blk_mq_init_flush().
Signed-off-by: Ming Lei
---
block/blk-flush.c | 11 ++-
block/blk-mq.c| 16 ++--
block/blk-mq.h|2 +-
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/block/blk-flush.c b/block/blk-
Now we use init_flush_rq callback to initialize pdu of
flush req.
Signed-off-by: Ming Lei
---
drivers/block/virtio_blk.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 0a58140..f478ec8 100644
---
Hi,
This patchset introduces init_flush_rq and its pair callback to
initialize pdu of flush request explicitly, instead of using
copying from request which is inefficient and buggy, and implements
them in virtio-blk and scsi-lib.
block/blk-flush.c | 22 +-
block/bl
Now implement init_flush_rq callback to avoid the unnecessary
pdu copying done in blk_mq_clone_flush_request().
The sense buffer is introduced to flush req, but it won't be
a deal since there is only one flush request per queue. It still
may be borrowed from the sence buffer of the request cloned
The in-tree drivers which need to handle flush request
have implemented init_flush_rq already, so don't
copy pdu any more for flush req.
Signed-off-by: Ming Lei
---
block/blk-mq.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 113d58d..16f595f
Currently pdu of the flush rq is simlpy copied from another rq,
turns out it isn't a good approach:
- it isn't enough to initialize pointer field well, and
easy to cause bugs if some pointers filed are included
in pdu
- the copy isn't necessary, because the pdu sho
I think that what confused Andy (or at least me) is the documentation in
Documentation/x86/pat.txt
If it's possible, can you please update pat.txt as part of the patch?
Thank you,
Yigal
On 04/09/2014 21:57, Toshi Kani wrote:
> On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote:
>> On Thu,
On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:
> > +MODULE_AUTHOR("Johannes Berg ");
> > +MODULE_DESCRIPTION("Device Coredump support");
> > +MODULE_LICENSE("GPL");
>
> As you only allow Y or N as build options, it's not really a "module" :)
Umm, yeah. I went back and forth on whet
Hello, I'm new to all this so please correct me if I'm sending this to
the wrong place. I'd like to report the following error that shows
whenever I run scripts/checkpatch.pl. The error shows at the top of
the output after which the script appears to function normally. I'm
running Arch Linux and
Annotate the lock/unlock pair in lov_stripe_lock/lov_stripe_unlock to
avoid sparse warning about a context imbalance.
Part of the eudyptula challenge: http://eudyptula-challenge.org/
Signed-off-by: Mostyn Bramley-Moore
---
drivers/staging/lustre/lustre/lov/lov_obd.c | 2 ++
1 file changed, 2 ins
On Fri, Sep 05, 2014 at 08:41:18PM +0200, Imre Palik wrote:
> From: "Palik, Imre"
>
> If the drbd backing device is a new device mapper device (e.g., a
> dm-linear mapping of an existing block device that contains data), the
> counters are initially 0 even though the device contains useful
> data
Il 07/09/2014 01:09, Christoph Hellwig ha scritto:
> Most virtio setups have a fairly limited number of ring entries available.
Are you disabling indirect descriptors? With indirect descriptors entry
merging doesn't buy you any more space, so perhaps you can key the flag
off the availability of V
Hi,
On 09/07/2014 01:02 AM, Richard Weinberger wrote:
Can you please find the offending commit?
Using an automated bisect run this should be easily doable.
That would be it:
da1ce0670c14d8380e423a3239e562a1dc15fa9e is the first bad commit
commit da1ce0670c14d8380e423a3239e562a1dc15fa9e
Author
The max_uV is not used, so remove it from struct as3711_regulator_info.
Current code is using devm_regulator_register(), so we don't need to store *rdev
in struct as3711_regulator for clean up.
Also clean up AS3711_REG macro to remove _vshift, _min_uV and _max_uV arguments.
_vshift is always 0, so
From: Vidya Sagar
As per PCIe spec, fast back-to-back transactions feature
is not applicable to PCIe devices. Hence, do not print
that fast back-to-back trasactions are disabled when
there is a PCIe device found on the bus
Signed-off-by: Vidya Sagar
---
v4:
* initialized 'has_pcie_dev' to 'fals
On Sun, Sep 7, 2014 at 7:09 AM, Christoph Hellwig wrote:
> Most virtio setups have a fairly limited number of ring entries available.
> Enable S/G entry merging by default to fit into less of them. This restores
> the behavior at time of the virtio-blk blk-mq conversion, which was changed
> by co
The max_uV is not used, so remove it from struct as3711_regulator_info.
Current code is using devm_regulator_register(), so we don't need to store *rdev
in struct as3711_regulator for clean up.
Also clean up AS3711_REG macro to remove _vshift, _min_uV and _max_uV arguments.
_vshift is always 0, so
Signed-off-by: Axel Lin
---
drivers/regulator/bcm590xx-regulator.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index 5d1fd6f..fe6ac69 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/r
2014-09-06 21:49 GMT+08:00 Mark Brown :
> On Sat, Sep 06, 2014 at 08:59:36PM +0800, Axel Lin wrote:
>> Signed-off-by: Axel Lin
>
> Applied, thanks. Please always send incremental patches.
Thanks, and sorry that I have limited internet access while traveling.
I did not realize that the v1 patch i
On Sat, Sep 6, 2014 at 1:45 AM, Alan Stern wrote:
> James and Jens:
>
> I got a WARNING when unbinding the sd driver from a USB flash drive and
> then binding it back again. Here's where the flash drive gets probed
> initially:
>
> [ 143.300886] usb-storage 4-8:1.0: usb_probe_interface
> [ 143.
Commit-ID: 177ef2a6315ea7bf173653182324e1dcd08ffeaa
Gitweb: http://git.kernel.org/tip/177ef2a6315ea7bf173653182324e1dcd08ffeaa
Author: xiaofeng.yan
AuthorDate: Tue, 26 Aug 2014 03:15:41 +
Committer: Ingo Molnar
CommitDate: Sun, 7 Sep 2014 11:09:59 +0200
sched/deadline: Fix a precis
Linus,
please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
Three fixlets from the timer departement:
- Update the timekeeper before updating vsyscall and pvclock. This
fixes the kvm-clock regress
1 - 100 of 179 matches
Mail list logo