, I will update it in v7.
Thanks,
--
Ming Lei
--
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/
On Wed, Nov 28, 2012 at 5:19 AM, Rafael J. Wysocki wrote:
> On Saturday, November 24, 2012 08:59:14 PM Ming Lei wrote:
>> The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
>> to help PM core to teach mm not allocating memory with GFP_KERNEL
>
ng the whole path can't be avoided too,
and may be a explicit walking or recursion, because pm_runtime_set_memalloc_noio
is required to set or clear the flag(or increase/decrease the counter) of
devices in the whole path.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line &qu
worthy of the obtained advantage.
So could you accept not introducing counter? and I will update with the
above improvement you suggested.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
;
>> Also, the function is only called by network device or block device
>> subsystem, both the two kind of device are class device and should
>> have no children.
>
> OK, so not walking the arg device's children is an optimization related to
> some assumptions
irent object, which will be put
again afterwards.
Hope we are luck this time, please try the attachment patch.
Thanks,
--
Ming Lei
sysfs-fix-readdir-v2.patch
Description: Binary data
Hi Sasha,
On Tue, Mar 19, 2013 at 11:40 AM, Ming Lei wrote:
> Hi Sasha,
>
> On Tue, Mar 19, 2013 at 10:06 AM, Sasha Levin wrote:
>> [ 232.822703] sysfs_dir_pos-973 sysfs_dirent use after free:
>> vx855(vx855)-bind, 0-25520352
>
> Looks filp->f_pos is changed as
Hi Sasha,
On Wed, Mar 20, 2013 at 12:28 AM, Sasha Levin wrote:
> On 03/19/2013 07:54 AM, Ming Lei wrote:
>
> With v3 of the patch:
>
> [ 1275.665758] sysfs_dir_pos-973 sysfs_dirent use after free:
> tun(tun)-uevent, 2-1472641949
Thanks again for your test.
Looks it is caused
e problem since
the lock is always held in readdir path.
Reported-by: Dave Jones
Tested-by: Sasha Levin
Cc:
Signed-off-by: Ming Lei
---
fs/sysfs/dir.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 2fbdff6..c9e1660 100644
gered later.
This patch returns immeadiately under the situation for fixing the bug,
and it is reasonable to return from readdir() when filldir() fails.
Reported-by: Dave Jones
Tested-by: Sasha Levin
Cc:
Signed-off-by: Ming Lei
---
fs/sysfs/dir.c |4
1 file changed, 4 insertions(+
Hi,
These two patches fix two bugs inside sysfs_readdir(), and both
the two bugs may cause use after free problem, which is reported
by Dave on trinity fuzz test on syscall.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Thu, Mar 21, 2013 at 10:41 AM, Li Zefan wrote:
>
> In fact the same race exists between readdir() and read()/write()...
Fortunately, no read()/write() are implemented on sysfs directory, :-)
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Thu, Mar 21, 2013 at 11:28 AM, Li Zefan wrote:
> On 2013/3/21 11:17, Ming Lei wrote:
>> On Thu, Mar 21, 2013 at 10:41 AM, Li Zefan wrote:
>>>
>>> In fact the same race exists between readdir() and read()/write()...
>>
>> Fortunately, no read()/wri
ard A1 frequently, looks not
see the failure problem before. Maybe the problem is config dependent.
If you may share your config file, I'd like to do the test too.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
: Sasha Levin
Signed-off-by: Ming Lei
---
fs/sysfs/dir.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 1bf016b..328ef9b 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -268,6 +268,13 @@ void release_sysfs_dirent(struct
On Wed, Apr 3, 2013 at 11:04 AM, Dave Jones wrote:
> On Wed, Apr 03, 2013 at 10:58:23AM +0800, Ming Lei wrote:
>
> > diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> > index 1bf016b..328ef9b 100644
> > --- a/fs/sysfs/dir.c
> > +++ b/fs/sysfs/dir.c
On Wed, Apr 3, 2013 at 1:35 PM, Greg Kroah-Hartman
wrote:
> On Wed, Apr 03, 2013 at 11:52:39AM +0800, Ming Lei wrote:
>> On Wed, Apr 3, 2013 at 11:04 AM, Dave Jones wrote:
>> > On Wed, Apr 03, 2013 at 10:58:23AM +0800, Ming Lei wrote:
>> >
>> > > diff
o Will Deacon, and looks no oops trace is generated
on the memory access exception during booting. And the hang
happened in mutex_unlock(&cgroup_mutex)(cgroup_init_subsys<-
cgroup_init_early).
> Sorry, not applying this until the above issue has been discussed
> and the location of these percp
and console might not be available at that time.
Thanks,
--
Ming Lei
--
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
: Sasha Levin
Signed-off-by: Ming Lei
---
v1:
- use WARN() instead of BUG() as suggested by Dave and Greg
fs/sysfs/dir.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 1bf016b..e8e0e71 100644
--- a/fs/sysfs/dir.c
+++ b/fs
e {
> - ret = _request_firmware_load(fw_priv, true,
> - firmware_loading_timeout());
> - usermodehelper_read_unlock();
> - }
> - if (ret)
> - _request_firmware_cleanup(firmware_p);
>
helper_read_unlock();
> - }
> - if (ret)
> - _request_firmware_cleanup(firmware_p);
> -
> - return ret;
> + return _request_firmware(firmware_p, name, device, true, false);
> }
>
> /**
> @@ -1046,33 +1091,12 @@ static void request_
you can do it in another patch for discussion
if you have better way to handle the situation.
Thanks,
--
Ming Lei
--
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/
On Wed, Jan 30, 2013 at 6:31 PM, Takashi Iwai wrote:
>
> But it's supposed to be cached, no?
Generally it will be cached, but some crazy devices might come as new
device during resume, so we still need to handle the situation.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: se
On Wed, Jan 30, 2013 at 6:53 PM, Takashi Iwai wrote:
> At Wed, 30 Jan 2013 18:50:05 +0800,
> Ming Lei wrote:
>>
>> On Wed, Jan 30, 2013 at 6:31 PM, Takashi Iwai wrote:
>> >
>> > But it's supposed to be cached, no?
>>
>> Generally it wil
On Wed, Jan 30, 2013 at 7:08 PM, Takashi Iwai wrote:
> At Wed, 30 Jan 2013 11:53:14 +0100,
> Takashi Iwai wrote:
>>
>> At Wed, 30 Jan 2013 18:50:05 +0800,
>> Ming Lei wrote:
>> >
>> > On Wed, Jan 30, 2013 at 6:31 PM, Takashi Iwai wrote:
>&g
flags;
bool has_info;
struct partition_meta_info info;
- } parts[DISK_MAX_PARTS];
+ } *parts;
int next;
int limit;
bool access_beyond_eod;
char *pp_buf;
};
+extern void release_partitions(struct parsed_partitions *state
are_loading_timeout();
The above line may be moved below the line of 'if (nowait) '.
> + if (nowait) {
> + timeout = usermodehelper_read_lock_wait(timeout);
> + if (!timeout) {
> + dev_dbg(device, "firmware: %s loadin
ny objection to me taking them?
No objections, and I have reviewed the patch set and acked them all.
Thanks,
--
Ming Lei
--
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/
On Fri, Feb 1, 2013 at 7:43 AM, Andrew Morton wrote:
> On Wed, 30 Jan 2013 19:53:22 +0800
> Ming Lei wrote:
>
>> The allocation failure is caused by the big sizeof(struct parsed_partitions),
>> which is 64K in my 32bit box,
>
> Geeze.
>
> W
a bit big for kmalloc
- given that many devices have the partition count limit, so only
allocate disk_max_parts() partitions instead of 256 partitions
Cc: sta...@vger.kernel.org
Signed-off-by: Ming Lei
---
block/partition-generic.c |2 +-
block/partitions/check.c | 35
arts;
>
> This is relatively unusual style.
> Could you break out this struct instead?
IMO, looks it isn't necessary since no one uses the type of the embedded
structure directly, and the style isn't introduced by this patch, which only
follows the previous one.
Thanks,
--
M
On Fri, Feb 1, 2013 at 4:33 PM, Yasuaki Ishimatsu
wrote:
> At least, you should use release_partitions() instead of kfree() here.
Good catch, thank you for pointing it out, and I will post v1 later
with the update.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the l
a bit big for kmalloc
- given that many devices have the partition count limit, so only
allocate disk_max_parts() partitions instead of 256 partitions
Cc: sta...@vger.kernel.org
Signed-off-by: Ming Lei
---
v1:
- add one missing free_partitions
- rename release_partitions as
On Tue, Jan 22, 2013 at 7:51 PM, Takashi Iwai wrote:
> Since 3.7 kernel, the firmware loader can read the firmware files
> directly, and the traditional user-mode helper is invoked only as a
> fallback. This seems working pretty well, and the next step would be
> to reduce the redundant user-mode
4, ignore the problem
Looks each approache have its own disadvantage, so what
is your opinion on the problem? or better approach?
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
It isn't necessary to read the information of partitions whose No.
is equal and more than state->limit since only maximum state->limit
partitions will be added inside rescan_partitions().
That is also what other kind of partitions are doing.
Signed-off-by: Ming Lei
---
block/parti
a bit big for kmalloc
- given that many devices have the partition count limit, so only
allocate disk_max_parts() partitions instead of 256 partitions always
Reported-by: Felipe Balbi
Signed-off-by: Ming Lei
---
block/partition-generic.c |4 ++--
block/partitions/check.c | 37
may fix the probem,
but looks both aren't perfect.
So the workaround is proposed in this patch...
Ingo and Peter, what is your opinion on the problem?
Thanks
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
; private pointer inside setup_per_cpu_areas().
Suppose so, seems the patch is still needed to make CPU0 see
static variables in '.data..percpu' section correctly.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Wed, Mar 13, 2013 at 1:25 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Mar 12, 2013 at 07:44:55PM +0800, Ming Lei wrote:
>> On Tue, Mar 12, 2013 at 7:30 PM, Russell King - ARM Linux
>> wrote:
>> >>
>> >> Ingo and Peter, what is your opinion on the
fs one below)
>
> Running 'trinity -c mkdirat -V /sys' doesn't seem to trigger it, so it's an
> interaction with something else maybe.
Maybe it is helpful for trinity to output some previous recorded operations
on /sysfs when the crash is triggered.
Thanks,
--
Mi
On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov wrote:
>> From: Ming Lei
>> Subject: atomic: improve
>> atomic_inc_unless_negative/atomic_dec_unless_positive
>>
>> Generally, both atomic_inc_unless_negative() and
>> atomic_dec_unless_positive() need at least
b 50 10 48 85 d2 75 f4 eb 2a 66 90 48 89 d1 48 83
>> e1 fc 74
>> [ 350.150035] RIP [] rb_next+0x23/0x60
>> [ 350.150035] RSP
>> [ 350.179705] ---[ end trace a39f58a515b594d5 ]---
>
> And on the bright side, unlike in Dave's case, similar issues reproduce
> rather easily
> over here:
Could you share how to reproduce that easily?
Thanks,
--
Ming Lei
--
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/
On Fri, Mar 15, 2013 at 9:46 PM, Oleg Nesterov wrote:
> On 03/15, Ming Lei wrote:
>>
>> On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov wrote:
>> > static inline int atomic_inc_unless_negative(atomic_t *p)
>> > {
>> > int v, v
\n",
+ __func__, parent_sd->s_name, pos->s_name);
sysfs_put(pos);
if (!valid)
pos = NULL;
Thanks,
--
Ming Lei
--
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/
27; or the node name
is changed every time?
Thanks,
--
Ming Lei
--
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/
ala
Cc: Michel Lespinasse
Cc: Andrew Morton
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
mm/fremap.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/fremap.c b/mm/fremap.c
index 6a8da7e..80088e9 100644
--- a/mm/fremap.c
+++ b/mm/fremap.c
@@ -129,7 +129,7 @@
On Sat, Mar 16, 2013 at 11:22 PM, Ming Lei wrote:
> On Sat, Mar 16, 2013 at 11:07 PM, Sasha Levin wrote:
>>
>> Hi Ming,
>>
>> With your patch:
>>
>>
>> [ 1525.874312] release_sysfs_dirent sysfs_dirent use after free: ptysb-uevent
>
> Sas
; [ 327.425263] [] SyS_getdents+0x8c/0x110
> [ 327.426173] [] tracesys+0xe1/0xe6
>
Sasha, looks there is a race when sys_readdir() is run concurrently
on same directory, and the below patch may fix the race, could you test the
attachment patch to see if the use after free can be fixed
On Sun, Mar 17, 2013 at 12:44 PM, Michel Lespinasse wrote:
> On Sat, Mar 16, 2013 at 8:23 AM, Ming Lei wrote:
>> Since find_vma() may return NULL, so don't dereference the
>> returned 'vma' until it is valid.
>
> Agree this was an issue. This is fixed with com
st out the log.
BTW, the attachment patch is only for verifying if the current problem
is caused by 'filp->private_data' race, and not for merge.
Thanks,
--
Ming Lei
sysfs-fix-readdir-v1.patch
Description: Binary data
amp;w=2
IMO, driver core needn't to be changed, and the defer probe can be
supported just by changes in request_firmware() and its caller.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
On Wed, Sep 5, 2012 at 12:10 AM, Takashi Iwai wrote:
> At Tue, 4 Sep 2012 23:52:15 +0800,
> Ming Lei wrote:
>>
>> On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote:
>> > Hi,
>> >
>> > as I've got recently a few bug reports regarding the stuck w
On Wed, Sep 5, 2012 at 1:53 PM, Takashi Iwai wrote:
> At Wed, 5 Sep 2012 09:15:34 +0800,
> Ming Lei wrote:
>>
>> On Wed, Sep 5, 2012 at 12:10 AM, Takashi Iwai wrote:
>> > At Tue, 4 Sep 2012 23:52:15 +0800,
>> > Ming Lei wrote:
>> >>
>>
, the mutex of
probing_active is held during the whole irq probe procedure, so
I don't understand why the above said that 'nothing prevents two
IRQ probe callers from overlapping", and why isn't the mutex of
probing_active enough to avoid the overlapping?
Thanks,
--
Ming Lei
--
imizes the cacheing firmware mechanism a bit by
only storing one firmware cache entry for one firmware image.
So if the firmware is still cached during suspend, it doesn't need
to be loaded from user space any more.
Signed-off-by: Ming Lei
---
drivers/base/firmware
On Tue, Oct 2, 2012 at 4:35 PM, Ming Lei wrote:
> ---
> drivers/base/firmware_class.c | 30 --
> 1 file changed, 24 insertions(+), 6 deletions(-)
Please ignore the buggy patch, sorry for the noise.
Thanks,
--
Ming Lei
--
To unsubscribe from this list:
On Tue, Oct 23, 2012 at 3:18 AM, Alan Stern wrote:
> On Mon, 22 Oct 2012, Ming Lei wrote:
> Is this really needed? Even with iSCSI, doesn't register_disk() have
> to be called for the underlying block device? And given your 3/6
> patch, wouldn't that mark the network d
On Mon, Oct 22, 2012 at 10:37 PM, Alan Stern wrote:
> On Mon, 22 Oct 2012, Ming Lei wrote:
>>
>> + /*
>> + * Don't allocate memory with GFP_KERNEL in current
>> + * context to avoid possible deadlock if usb mass
>> + * storage in
the simplest way is to add a global lock. Any suggestion?
>
> Even without a race, access to bitfields is not SMP-safe
> without locking.
You mean one ancestor device might not be in active when
one of its descendants is being probed or removed?
Thanks,
--
Ming Lei
--
T
ware just after rootfs is mounted.
kernel parameter should be a good way to pass one customerized
path.
Thanks,
--
Ming Lei
--
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://vge
irmware path listing.
>
> Should I amend the commit description so it is not misleading and
> remove the 'updating' part?
In fact, I also questioned on path listing too in last thread too.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linu
Cc: Samuel Thibault
Cc: Joe Perches
Signed-off-by: Ming Lei
---
kernel/printk/braille.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/braille.h b/kernel/printk/braille.h
index d2e6bc3..769d771 100644
--- a/kernel/printk/braille.h
+++ b/kernel/printk/brai
On Tue, Oct 23, 2012 at 9:44 PM, Dimitris Papastamos
wrote:
>
> I don't currently have a use-case for this, so not sure how useful
> it is to list the default fw paths.
OK, got it, thanks for your effort.
Greg, so could we just hold on until it is useful?
Thanks,
--
Ming Lei
--
On Tue, Oct 23, 2012 at 10:46 PM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Ming Lei wrote:
>
>> On Mon, Oct 22, 2012 at 10:33 PM, Alan Stern
>> wrote:
>> >
>> > Tail recursion should be implemented as a loop, not as an explicit
>> > recursion. Th
This patch adds description on recently introduced direct firmware
loading by Linus.
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
Documentation/firmware_class/README | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/Documentation/firmware_class
This patch introduces one kernel parameter of 'fw_path' to support
customizing firmware image search path, so that people can use its
own firmware path if the default built-in paths can't meet their demand[1].
[1], https://lkml.org/lkml/2012/10/11/337
Cc: Linus Torvalds
Signed-o
have a /lib/ directory, can override it easily.
Sound like still a solution, :-)
If you agree on module parameter, that might be more flexible, IMO
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
eter, sorry about that.
Thanks,
--
Ming Lei
--
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/
rder looked before. This is
> just a first heads-up in case someone has a solution immediately at hand.
Thanks,
--
Ming Lei
--
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/
mmand
parameter when 'firmware_class' is built in kernel:
firmware_class.path=$CUSTOMIZED_PATH
[1], https://lkml.org/lkml/2012/10/11/337
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
V1:
- remove kernel boot parameter and only support the feature by
module
firmware/updates/" UTS_RELEASE,
"/lib/firmware/updates",
"/lib/firmware/" UTS_RELEASE,
"/lib/firmware"
};
but in fact there isn't any warning with above change and it does work, still
don't know why? :-(
mpler to set the noio flag during every
> device reset.
Yes, it's better to set the flag during every device reset now.
Also pppoe or network interface over serial port is a bit difficult to
deal with, as Oliver pointed out.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send t
mm/page_alloc.c | 10 -
mm/vmscan.c | 12 ++
net/core/net-sysfs.c |5 +++
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majord
) may allocate memory
with GFP_KERNEL.
Cc: Alan Stern
Cc: Oliver Neukum
Cc: Jiri Kosina
Cc: Andrew Morton
Cc: Mel Gorman
Cc: KAMEZAWA Hiroyuki
Cc: Michal Hocko
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
Signed-off-by: Minchan Kim
Signed-off-by: Ming Lei
-
device in
the path from one block or network device to the root device
in the device tree may cause deadlock, the introduced
pm_runtime_set_memalloc_noio() sets or clears the flag on
device in the path recursively.
Cc: Alan Stern
Cc: "Rafael J. Wysocki"
Signed-off-by: Ming Lei
---
This patch applyes the introduced pm_runtime_set_memalloc_noio on
block device so that PM core will teach mm to not allocate memory with
GFP_IOFS when calling the runtime_resume and runtime_suspend callback
for block devices and its ancestors.
Cc: Jens Axboe
Signed-off-by: Ming Lei
---
v4
ller"
Cc: Eric Dumazet
Cc: David Decotigny
Cc: Tom Herbert
Cc: Ingo Molnar
Signed-off-by: Ming Lei
---
v4:
- call pm_runtime_set_memalloc_noio(ddev, true) after
device_add
---
net/core/net-sysfs.c |5 +
1 file changed, 5 insertions(+)
diff --git a/net/core/net-sy
This patch applies the introduced memalloc_noio_save() and
memalloc_noio_restore() to force memory allocation with no I/O
during runtime_resume/runtime_suspend callback on device with
the flag of 'memalloc_noio' set.
Cc: Alan Stern
Cc: Oliver Neukum
Cc: Rafael J. Wysocki
Signed-of
set() and the storage
interface can't do I/O transfer when the reset is triggered
by other interface, or the error handling can't be completed
if the reset is triggered by the storage itself(error handling path).
Cc: Alan Stern
Cc: Oliver Neukum
Signed-off-by: Ming Lei
---
v4:
- mar
mmand
parameter when 'firmware_class' is built in kernel:
firmware_class.path=$CUSTOMIZED_PATH
[1], https://lkml.org/lkml/2012/10/11/337
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
v4:
- fix one comment and rebase on the latest next tree
v3:
- fix one
From: Ming Lei
This patch documents the firmware cache mechanism so that
users of request_firmware() know that it can be called
safely inside device's suspend and resume callback, and
the device's firmware needn't be cached any more by individual
driver itself to deal with firmw
On Thu, Jul 26, 2012 at 12:15 AM, Borislav Petkov wrote:
> On Wed, Jul 25, 2012 at 01:00:09AM +0800, Ming Lei wrote:
>> This patch will store firmware name into devres list of the device
>> which is requesting firmware loading, so that we can implement
>> auto cache firmwar
On Thu, Jul 26, 2012 at 12:52 AM, Borislav Petkov wrote:
> On Wed, Jul 25, 2012 at 01:00:11AM +0800, Ming Lei wrote:
>> This patches introduces the three helpers below:
>>
>> void device_cache_firmwares(void)
>> void device_uncache_fi
quot;short" is very
> misleading in such explanations so please be more specific as to why the
It is the original one, and I don't think it is wrong. Also it
shouldn't be covered
by this patch.
Maybe I shouldn't have fixed the comment in this patch.
Thanks,
On Thu, Jul 26, 2012 at 8:36 PM, Borislav Petkov wrote:
> On Wed, Jul 25, 2012 at 01:00:12AM +0800, Ming Lei wrote:
>> Because device_cache_firmwares only cache the firmware which has been
>> loaded sucessfully at leat once, using a small loading timeout should
>
>
On Thu, Jul 26, 2012 at 8:43 PM, Borislav Petkov wrote:
>> +#else
>> +static int fw_pm_notify(struct notifier_block *notify_block,
>> + unsigned long mode, void *unused)
>> +{}
>
> static inline int fw_pm...
Will add inline in -v
On Thu, Jul 26, 2012 at 12:25 AM, Borislav Petkov wrote:
> On Wed, Jul 25, 2012 at 01:00:10AM +0800, Ming Lei wrote:
>> This patch introduces one devres API of devres_for_each_res
>> so that the device's driver can iterate each resource it has
>> interest in.
>>
On Fri, Jul 27, 2012 at 3:43 AM, Don Zickus wrote:
> On Wed, Jul 25, 2012 at 12:39:45PM +0800, Ming Lei wrote:
>> Use raw_smp_processor_id in lockup_detector_bootcpu_resume()
>> because it is enough when non-boot CPUs are offline.
>>
>> This patch fixes the following
On Fri, Jul 27, 2012 at 1:46 AM, Borislav Petkov wrote:
> On Thu, Jul 26, 2012 at 11:44:48PM +0800, Ming Lei wrote:
>> On Thu, Jul 26, 2012 at 8:20 PM, Borislav Petkov wrote:
>> >
>> > Ok, here's what I got from looking at the patch:
>>
smaller timeout instead of simply doing the completion
> without a timeout?
No, it should be crazy without a timeout, and it can be triggered in init call
easily.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
On Fri, Jul 27, 2012 at 6:35 PM, Borislav Petkov wrote:
> On Fri, Jul 27, 2012 at 09:54:25AM +0800, Ming Lei wrote:
>> On Fri, Jul 27, 2012 at 1:54 AM, Borislav Petkov wrote:
>>
>> >> No, it is not what I was saying.
>>
>> I just mean the point is not men
e drivers requesting firmware in their
> ->probe() methods."
Fairly enough, will add this kind of description in -v1, and I will introduce
one extra patch to fix this comment since it is nothing related with the
device lifetime fix and its comments.
Thanks,
--
Ming Lei
--
To unsubscribe
mmand
parameter when 'firmware_class' is built in kernel:
firmware_class.path=$CUSTOMIZED_PATH
[1], https://lkml.org/lkml/2012/10/11/337
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
v2
- take a cleaner approach suggested by Linus
- mark the path array as co
On Fri, Oct 26, 2012 at 10:51 PM, Ming Lei wrote:
> +
> + /* skip the unset customized path */
> + if (!fw_path[0])
There is one mistake above and should be below, sorry for the noise.
if (!fw_path[i][0])
Thanks,
--
Ming Lei
--
To un
mmand
parameter when 'firmware_class' is built in kernel:
firmware_class.path=$CUSTOMIZED_PATH
[1], https://lkml.org/lkml/2012/10/11/337
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
v3
- fix one mistake on checking unset firmware path
v2
- take a cleaner ap
96.
>> + * Typical usage is that passing 'firmware_class.path=$CUSTOMIZED_PATH'
>> + * from kernel command because firmware_class is generally built in
> do you mean kernel command line?
Yes.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsub
On Sun, Oct 28, 2012 at 6:37 AM, Cesar Eduardo Barros wrote:
> The comment above fw_file_size() suggests it is noinline for stack size
> reasons. Use noinline_for_stack to make this more clear.
Acked-by: Ming Lei
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send th
|1 +
include/linux/pm_runtime.h |5 +++
include/linux/sched.h| 10 +
mm/page_alloc.c | 10 -
mm/vmscan.c | 12 ++
net/core/net-sysfs.c |5 +++
9 files changed, 152 insertions(+), 2 deletions(-)
Thanks,
--
Ming Lei
--
1 - 100 of 2944 matches
Mail list logo
