Re: [RESEND][PATCH 0/2] staging: sm750fb: trivial style fixes.

[Greg Kroah-Hartman]

On Mon, Mar 04, 2019 at 12:55:30AM +0800, Yifeng Li wrote:
> Hello.
> 
> >From January to February, there have been two trivial sm750fb patches
> submitted to linux-fbdev, one by me, one by Jin Chen, but both without
> any response. Further, it seems both maintainers, Sudip Mukherjee and
> Teddy Wang, are currently unavailable, getting an "Ack-by" would be
> unfeasible.
> 
> Since they're extremely trivial. Hereby, I picked them up, reworded
> commit message, and now resubmit them as trivial patches, and send them
> to triv...@kernel.org. I hope it could be directly applied by either a
> fbdev, a staging maintainer or by Jiri Kosina.

staging patches need to go to me, as get_maintainers.pl says to send
them.  I'll queue these up in a bit, but no need to bother trivial@ with
staging stuff, otherwise that would be all it did :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: pidfd design

[Christian Brauner]

On Tue, Mar 19, 2019 at 07:42:52PM -0700, Daniel Colascione wrote:
> On Tue, Mar 19, 2019 at 6:52 PM Joel Fernandes  wrote:
> >
> > On Wed, Mar 20, 2019 at 12:10:23AM +0100, Christian Brauner wrote:
> > > On Tue, Mar 19, 2019 at 03:48:32PM -0700, Daniel Colascione wrote:
> > > > On Tue, Mar 19, 2019 at 3:14 PM Christian Brauner 
> > > >  wrote:
> > > > > So I dislike the idea of allocating new inodes from the procfs super
> > > > > block. I would like to avoid pinning the whole pidfd concept 
> > > > > exclusively
> > > > > to proc. The idea is that the pidfd API will be useable through procfs
> > > > > via open("/proc/") because that is what users expect and really
> > > > > wanted to have for a long time. So it makes sense to have this 
> > > > > working.
> > > > > But it should really be useable without it. That's why translate_pid()
> > > > > and pidfd_clone() are on the table.  What I'm saying is, once the 
> > > > > pidfd
> > > > > api is "complete" you should be able to set CONFIG_PROCFS=N - even
> > > > > though that's crazy - and still be able to use pidfds. This is also a
> > > > > point akpm asked about when I did the pidfd_send_signal work.
> > > >
> > > > I agree that you shouldn't need CONFIG_PROCFS=Y to use pidfds. One
> > > > crazy idea that I was discussing with Joel the other day is to just
> > > > make CONFIG_PROCFS=Y mandatory and provide a new get_procfs_root()
> > > > system call that returned, out of thin air and independent of the
> > > > mount table, a procfs root directory file descriptor for the caller's
> > > > PID namspace and suitable for use with openat(2).
> > >
> > > Even if this works I'm pretty sure that Al and a lot of others will not
> > > be happy about this. A syscall to get an fd to /proc?
> 
> Why not? procfs provides access to a lot of core kernel functionality.
> Why should you need a mountpoint to get to it?
> 
> > That's not going
> > > to happen and I don't see the need for a separate syscall just for that.
> 
> We need a system call for the same reason we need a getrandom(2): you
> have to bootstrap somehow when you're in a minimal environment.
> 
> > > (I do see the point of making CONFIG_PROCFS=y the default btw.)
> 
> I'm not proposing that we make CONFIG_PROCFS=y the default. I'm
> proposing that we *hardwire* it as the default and just declare that
> it's not possible to build a Linux kernel that doesn't include procfs.
> Why do we even have that button?
> 
> > I think his point here was that he wanted a handle to procfs no matter where
> > it was mounted and then can later use openat on that. Agreed that it may be
> > unnecessary unless there is a usecase for it, and especially if the /proc
> > directory being the defacto mountpoint for procfs is a universal convention.
> 
> If it's a universal convention and, in practice, everyone needs proc
> mounted anyway, so what's the harm in hardwiring CONFIG_PROCFS=y? If
> we advertise /proc as not merely some kind of optional debug interface
> but *the* way certain kernel features are exposed --- and there's
> nothing wrong with that --- then we should give programs access to
> these core kernel features in a way that doesn't depend on userspace
> kernel configuration, and you do that by either providing a
> procfs-root-getting system call or just hardwiring the "/proc/" prefix
> into VFS.
> 
> > > Inode allocation from the procfs mount for the file descriptors Joel
> > > wants is not correct. Their not really procfs file descriptors so this
> > > is a nack. We can't just hook into proc that way.
> >
> > I was not particular about using procfs mount for the FDs but that's the 
> > only
> > way I knew how to do it until you pointed out anon_inode (my grep skills
> > missed that), so thank you!
> >
> > > > C'mon: /proc is used by everyone today and almost every program breaks
> > > > if it's not around. The string "/proc" is already de facto kernel ABI.
> > > > Let's just drop the pretense of /proc being optional and bake it into
> > > > the kernel proper, then give programs a way to get to /proc that isn't
> > > > tied to any particular mount configuration. This way, we don't need a
> > > > translate_pid(), since callers can just use procfs to do the same
> > > > thing. (That is, if I understand correctly what translate_pid does.)
> > >
> > > I'm not sure what you think translate_pid() is doing since you're not
> > > saying what you think it does.
> > > Examples from the old patchset:
> > > translate_pid(pid, ns, -1)  - get pid in our pid namespace
> 
> Ah, it's a bit different from what I had in mind. It's fair to want to
> translate PIDs between namespaces, but the only way to make the
> translate_pid under discussion robust is to have it accept and produce
> pidfds. (At that point, you might as well call it translate_pidfd.) We
> should not be adding new APIs to the kernel that accept numeric PIDs:

The traditional pid-based api is not going away. There are users that
have the requirement to translate 

Re: [PATCH] staging: erofs: fix parenthesis alignment

[Gao Xiang]

On 2019/3/20 11:22, Gao Xiang wrote:
> Hi Julian,
> 
> On 2019/3/20 1:19, Julian Merida wrote:
>> Yes that was my mistake, I'm really sorry!! This was my first contribution 
>> to the kernel and I didn't know who to send the email despite the 
>> maintainers. Also, I thought I shouldn't bother more than necessary.
>>
>> Gao then told me I should send the patch to you and to the staging mail list.
>>
>> Regards,
>> Julián Mérida
> 
> [ kindly reminder: It is preferred to send in plain text rather than
>   html format since a lot of community guys and mailing lists could
>   treat them as spam emails...]

my fault, please ignore my reply... it shows your reply in different style...

Thanks,
Gao Xiang

> 
> Good luck...
> 
> Thanks,
> Gao Xiang
> 
>>
>> On Tue, Mar 19, 2019, 10:35 Gao Xiang > > wrote:
>>
>> Hi Greg,
>>
>> On 2019/3/19 21:28, Greg KH wrote:
>> > On Mon, Mar 18, 2019 at 08:58:41PM -0300, Julian Merida wrote:
>> >> Fix all checkpatch issues: "CHECK: Alignment should match open 
>> parenthesis"
>> >>
>> >> Signed-off-by: Julian Merida > >
>> >> Reviewed-by: Gao Xiang > >
>> >
>> > Was this really reviewed by Gao?  Offline or on-list?  I missed it if 
>> it
>> > was on-list :(
>>
>> Yes, I was reviewed on the first version...
>>
>> He didn't cc you and staging mailing list...
>> https://lists.ozlabs.org/pipermail/linux-erofs/2019-March/001486.html
>>
>> It seems no logic change and doing a lot of fixes...
>>
>> Thanks,
>> Gao Xiang
>>
>> >
>> > thanks,
>> >
>> > greg k-h
>> >
>>
>>
>> On Tue, Mar 19, 2019, 10:35 Gao Xiang > > wrote:
>>
>> Hi Greg,
>>
>> On 2019/3/19 21:28, Greg KH wrote:
>> > On Mon, Mar 18, 2019 at 08:58:41PM -0300, Julian Merida wrote:
>> >> Fix all checkpatch issues: "CHECK: Alignment should match open 
>> parenthesis"
>> >>
>> >> Signed-off-by: Julian Merida > >
>> >> Reviewed-by: Gao Xiang > >
>> >
>> > Was this really reviewed by Gao?  Offline or on-list?  I missed it if 
>> it
>> > was on-list :(
>>
>> Yes, I was reviewed on the first version...
>>
>> He didn't cc you and staging mailing list...
>> https://lists.ozlabs.org/pipermail/linux-erofs/2019-March/001486.html
>>
>> It seems no logic change and doing a lot of fixes...
>>
>> Thanks,
>> Gao Xiang
>>
>> >
>> > thanks,
>> >
>> > greg k-h
>> >
>>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: fix parenthesis alignment

[Gao Xiang]

Hi Julian,

On 2019/3/20 1:19, Julian Merida wrote:
> Yes that was my mistake, I'm really sorry!! This was my first contribution to 
> the kernel and I didn't know who to send the email despite the maintainers. 
> Also, I thought I shouldn't bother more than necessary.
> 
> Gao then told me I should send the patch to you and to the staging mail list.
> 
> Regards,
> Julián Mérida

[ kindly reminder: It is preferred to send in plain text rather than
  html format since a lot of community guys and mailing lists could
  treat them as spam emails...]

Good luck...

Thanks,
Gao Xiang

> 
> On Tue, Mar 19, 2019, 10:35 Gao Xiang  > wrote:
> 
> Hi Greg,
> 
> On 2019/3/19 21:28, Greg KH wrote:
> > On Mon, Mar 18, 2019 at 08:58:41PM -0300, Julian Merida wrote:
> >> Fix all checkpatch issues: "CHECK: Alignment should match open 
> parenthesis"
> >>
> >> Signed-off-by: Julian Merida  >
> >> Reviewed-by: Gao Xiang  >
> >
> > Was this really reviewed by Gao?  Offline or on-list?  I missed it if it
> > was on-list :(
> 
> Yes, I was reviewed on the first version...
> 
> He didn't cc you and staging mailing list...
> https://lists.ozlabs.org/pipermail/linux-erofs/2019-March/001486.html
> 
> It seems no logic change and doing a lot of fixes...
> 
> Thanks,
> Gao Xiang
> 
> >
> > thanks,
> >
> > greg k-h
> >
> 
> 
> On Tue, Mar 19, 2019, 10:35 Gao Xiang  > wrote:
> 
> Hi Greg,
> 
> On 2019/3/19 21:28, Greg KH wrote:
> > On Mon, Mar 18, 2019 at 08:58:41PM -0300, Julian Merida wrote:
> >> Fix all checkpatch issues: "CHECK: Alignment should match open 
> parenthesis"
> >>
> >> Signed-off-by: Julian Merida  >
> >> Reviewed-by: Gao Xiang  >
> >
> > Was this really reviewed by Gao?  Offline or on-list?  I missed it if it
> > was on-list :(
> 
> Yes, I was reviewed on the first version...
> 
> He didn't cc you and staging mailing list...
> https://lists.ozlabs.org/pipermail/linux-erofs/2019-March/001486.html
> 
> It seems no logic change and doing a lot of fixes...
> 
> Thanks,
> Gao Xiang
> 
> >
> > thanks,
> >
> > greg k-h
> >
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite

[Paul Moore]

On Tue, Mar 19, 2019 at 9:08 PM Todd Kjos  wrote:
> Paul,
>
> Looking at a snippet of the test output:
>
> Service Provider read_consumed: 8
> Service Provider command: BR_NOOP
> Service Provider command: BR_FAILED_REPLY  <-- the txn
> failed as expected.
> Manager read_consumed: 8
> Manager command: BR_NOOP
> Manager command: BR_TRANSACTION_COMPLETE
> not ok 3
> <- but for some reason didn't exit(103)
> #   Failed test at ./test line 56.
>
> It looks like the test script expects test_binder to fail with
> exit(103) after processing the Server Provider commands. It's not
> clear why it didn't, since the return of a BR_FAILED_REPLY for that
> transaction should have executed this code (line 392 of
> test_binder.c):
>
> if (cmd == BR_FAILED_REPLY ||
> cmd == BR_DEAD_REPLY ||
> cmd == BR_DEAD_BINDER) {
> fprintf(stderr,
>   "Failed response from Service Provider using Managers 
> FD\n");
> exit(103);
> }
>
> Could this be an issue with the test? At least it doesn't look like a
> transaction is succeeding when it shouldn't.

Hi Todd,

Thanks for looking into this further.  Look a bit more at the test, it
appears that the code above (line 392) only comes into play if the
service provider is handling a BR_REPLY, but looking at the test
output it doesn't appear that this is the case.

# runcon -t test_binder_provider_no_im_t ./test_binder -v -r 2 provider
Service Provider PID: 2095 Process context:
   unconfined_u:unconfined_r:test_binder_provider_no_im_t:s0-s0:c0.c1023
Service Provider sending transaction to Manager - ADD_TEST_SERVICE
Service Provider read_consumed: 48
Service Provider command: BR_NOOP
Service Provider command: BR_INCREFS
Service Provider command: BR_ACQUIRE
Service Provider command: BR_TRANSACTION_COMPLETE

Service Provider read_consumed: 8
Service Provider command: BR_NOOP
Service Provider command: BR_FAILED_REPLY

However, things get weird.  In the course of writing this email I
booted into my 5.0.0-1.1.secnext kernel (which passed the binder test
earlier) and now that kernel is failing in the same way (the test
hasn't changed).  This test system is a Fedora Rawhide system which is
updated before I make a test run and I'm wondering if there is some
other userspace component which may be affecting this ... ?  I've now
tried this on two different, current Rawhide VMs, hosted on two
different systems and I'm seeing the same thing, so I don't think it's
a *bad* system/VM?

> On Tue, Mar 19, 2019 at 5:15 PM Todd Kjos  wrote:
> >
> > [...]
> >
> > > > Is there a public dashboard where I can take a look at those binder 
> > > > failures?
> > >
> > > Not really.  I send test results to a not-yet-publicized mailing list,
> > > but there is more detail in the GitHub issue below (my last comment
> > > has the verbose test output):
> > >
> > > * https://github.com/SELinuxProject/selinux-kernel/issues/46
> > >
> >
> > Ok, so it looks like something was introduced that causes binder to be
> > too permissive (test 3 transaction succeeded when failure is
> > expected). I don't know of any recent binder changes that could have
> > caused that.
> >
> > It will take me a while to set up this test environment. Is this easy
> > for you to run? Any chance of bisecting or at least trying a few
> > versions to narrow it down? Here's a list of the recent patchset -- it
> > would be useful to know which caused it (or if none of them did):
> >
> > 9e98c678c2d6a Linux 5.1-rc1
> > ...
> > 26528be6720bb binder: fix handling of misaligned binder object
> > bde4a19fc04f5 binder: use userspace pointer as base of buffer space
> > c41358a5f5217 binder: remove user_buffer_offset
> > db6b0b810bf94 binder: avoid kernel vm_area for buffer fixups
> > 7a67a39320dfb binder: add function to copy binder object from buffer
> > 8ced0c6231ead binder: add functions to copy to/from binder buffers
> > 1a7c3d9bb7a92 binder: create userspace-to-binder-buffer copy function
> > ...
> > 1c163f4c7b3f6 (tag: v5.0) Linux 5.0
> >
> > Thanks,
> >
> > -Todd



--
paul moore
www.paul-moore.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

[Joel Fernandes]

On Wed, Mar 20, 2019 at 12:10:23AM +0100, Christian Brauner wrote:
> On Tue, Mar 19, 2019 at 03:48:32PM -0700, Daniel Colascione wrote:
> > On Tue, Mar 19, 2019 at 3:14 PM Christian Brauner  
> > wrote:
> > > So I dislike the idea of allocating new inodes from the procfs super
> > > block. I would like to avoid pinning the whole pidfd concept exclusively
> > > to proc. The idea is that the pidfd API will be useable through procfs
> > > via open("/proc/") because that is what users expect and really
> > > wanted to have for a long time. So it makes sense to have this working.
> > > But it should really be useable without it. That's why translate_pid()
> > > and pidfd_clone() are on the table.  What I'm saying is, once the pidfd
> > > api is "complete" you should be able to set CONFIG_PROCFS=N - even
> > > though that's crazy - and still be able to use pidfds. This is also a
> > > point akpm asked about when I did the pidfd_send_signal work.
> > 
> > I agree that you shouldn't need CONFIG_PROCFS=Y to use pidfds. One
> > crazy idea that I was discussing with Joel the other day is to just
> > make CONFIG_PROCFS=Y mandatory and provide a new get_procfs_root()
> > system call that returned, out of thin air and independent of the
> > mount table, a procfs root directory file descriptor for the caller's
> > PID namspace and suitable for use with openat(2).
> 
> Even if this works I'm pretty sure that Al and a lot of others will not
> be happy about this. A syscall to get an fd to /proc? That's not going
> to happen and I don't see the need for a separate syscall just for that.
> (I do see the point of making CONFIG_PROCFS=y the default btw.)

I think his point here was that he wanted a handle to procfs no matter where
it was mounted and then can later use openat on that. Agreed that it may be
unnecessary unless there is a usecase for it, and especially if the /proc
directory being the defacto mountpoint for procfs is a universal convention.

> Inode allocation from the procfs mount for the file descriptors Joel
> wants is not correct. Their not really procfs file descriptors so this
> is a nack. We can't just hook into proc that way.

I was not particular about using procfs mount for the FDs but that's the only
way I knew how to do it until you pointed out anon_inode (my grep skills
missed that), so thank you!

> > C'mon: /proc is used by everyone today and almost every program breaks
> > if it's not around. The string "/proc" is already de facto kernel ABI.
> > Let's just drop the pretense of /proc being optional and bake it into
> > the kernel proper, then give programs a way to get to /proc that isn't
> > tied to any particular mount configuration. This way, we don't need a
> > translate_pid(), since callers can just use procfs to do the same
> > thing. (That is, if I understand correctly what translate_pid does.)
> 
> I'm not sure what you think translate_pid() is doing since you're not
> saying what you think it does.
> Examples from the old patchset:
> translate_pid(pid, ns, -1)  - get pid in our pid namespace
> translate_pid(pid, -1, ns)  - get pid in other pid namespace
> translate_pid(1, ns, -1)- get pid of init task for namespace
> translate_pid(pid, -1, ns) > 0  - is pid is reachable from ns?
> translate_pid(1, ns1, ns2) > 0  - is ns1 inside ns2?
> translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
> translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
> 
> Allowing this syscall to yield pidfds as proper regular file fds and
> also taking pidfds as argument is an excellent way to kill a few
> problems at once:
> - cheap pid namespace introspection
> - creates a bridge between the "old" pid-based api and the "new" pidfd api

This second point would solve the problem of getting a new pidfd given a pid
indeed, without depending on /proc/ at all. So kudos for that and I am
glad you are making it return pidfds (but correct me if I misunderstood what
you're planning to do with translate_fd). It also obviates any need for
dealing with procfs mount points.

> - allows us to get proper non-directory file descriptors for any pids we
>   like

Here I got a bit lost. AIUI pidfd is a directory fd. Why would we want it to
not be a directory fd? That would be ambigiuous with what pidfd_send_signal
expects.

Also would it be a bad idea to extend translate_pid to also do what we want
for the pidfd_wait syscall?  So translate_fd in this case would return an fd
that is just used for the pid's death status.

All of these extensions seem to mean translate_pid should probably take a
fourth parameter that tells it the target translation type?

They way I am hypothesizing, translate_pid, it should probably be
- translation to a pid in some ns
- translation of a pid to a pidfd
- translation of a pid to a "wait" fd which returns the death/reap process 
status.

If that makes sense, that would also avoid the need for a new syscall we are 
adding.

> The additional advantage is that people are already happy to 

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

[Christian Brauner]

On Tue, Mar 19, 2019 at 03:48:32PM -0700, Daniel Colascione wrote:
> On Tue, Mar 19, 2019 at 3:14 PM Christian Brauner  
> wrote:
> > So I dislike the idea of allocating new inodes from the procfs super
> > block. I would like to avoid pinning the whole pidfd concept exclusively
> > to proc. The idea is that the pidfd API will be useable through procfs
> > via open("/proc/") because that is what users expect and really
> > wanted to have for a long time. So it makes sense to have this working.
> > But it should really be useable without it. That's why translate_pid()
> > and pidfd_clone() are on the table.  What I'm saying is, once the pidfd
> > api is "complete" you should be able to set CONFIG_PROCFS=N - even
> > though that's crazy - and still be able to use pidfds. This is also a
> > point akpm asked about when I did the pidfd_send_signal work.
> 
> I agree that you shouldn't need CONFIG_PROCFS=Y to use pidfds. One
> crazy idea that I was discussing with Joel the other day is to just
> make CONFIG_PROCFS=Y mandatory and provide a new get_procfs_root()
> system call that returned, out of thin air and independent of the
> mount table, a procfs root directory file descriptor for the caller's
> PID namspace and suitable for use with openat(2).

Even if this works I'm pretty sure that Al and a lot of others will not
be happy about this. A syscall to get an fd to /proc? That's not going
to happen and I don't see the need for a separate syscall just for that.
(I do see the point of making CONFIG_PROCFS=y the default btw.)

Inode allocation from the procfs mount for the file descriptors Joel
wants is not correct. Their not really procfs file descriptors so this
is a nack. We can't just hook into proc that way.

> 
> C'mon: /proc is used by everyone today and almost every program breaks
> if it's not around. The string "/proc" is already de facto kernel ABI.
> Let's just drop the pretense of /proc being optional and bake it into
> the kernel proper, then give programs a way to get to /proc that isn't
> tied to any particular mount configuration. This way, we don't need a
> translate_pid(), since callers can just use procfs to do the same
> thing. (That is, if I understand correctly what translate_pid does.)

I'm not sure what you think translate_pid() is doing since you're not
saying what you think it does.
Examples from the old patchset:
translate_pid(pid, ns, -1)  - get pid in our pid namespace
translate_pid(pid, -1, ns)  - get pid in other pid namespace
translate_pid(1, ns, -1)- get pid of init task for namespace
translate_pid(pid, -1, ns) > 0  - is pid is reachable from ns?
translate_pid(1, ns1, ns2) > 0  - is ns1 inside ns2?
translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?

Allowing this syscall to yield pidfds as proper regular file fds and
also taking pidfds as argument is an excellent way to kill a few
problems at once:
- cheap pid namespace introspection
- creates a bridge between the "old" pid-based api and the "new" pidfd api
- allows us to get proper non-directory file descriptors for any pids we
  like

The additional advantage is that people are already happy to add this
syscall so simply extending it and routing it through the pidfd tree or
Eric's tree is reasonable. (It should probably grow a flag argument. I
need to start prototyping this.)

> 
> We still need a pidfd_clone() for atomicity reasons, but that's a
> separate story. My goal is to be able to write a library that

Yes, on my todo list and I have a ported patch based on prior working
rotting somehwere on my git server.

> transparently creates and manages a helper child process even in a
> "hostile" process environment in which some other uncoordinated thread
> is constantly doing a waitpid(-1) (e.g., the JVM).
> 
> > So instead of going throught proc we should probably do what David has
> > been doing in the mount API and come to rely on anone_inode. So
> > something like:
> >
> > fd = anon_inode_getfd("pidfd", _fops, file_priv_data, flags);
> >
> > and stash information such as pid namespace etc. in a pidfd struct or
> > something that we then can stash file->private_data of the new file.
> > This also lets us avoid all this open coding done here.
> > Another advantage is that anon_inodes is its own kernel-internal
> > filesystem.
> 
> Sure. That works too.

Great.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

[Joel Fernandes]

On Tue, Mar 19, 2019 at 11:14:17PM +0100, Christian Brauner wrote:
[snip] 
> > 
> > ---8<---
> > 
> > From: Joel Fernandes 
> > Subject: [PATCH] Partial skeleton prototype of pidfd_wait frontend
> > 
> > Signed-off-by: Joel Fernandes 
> > ---
> >  arch/x86/entry/syscalls/syscall_32.tbl |  1 +
> >  arch/x86/entry/syscalls/syscall_64.tbl |  1 +
> >  include/linux/syscalls.h   |  1 +
> >  include/uapi/asm-generic/unistd.h  |  4 +-
> >  kernel/signal.c| 62 ++
> >  kernel/sys_ni.c|  3 ++
> >  6 files changed, 71 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
> > b/arch/x86/entry/syscalls/syscall_32.tbl
> > index 1f9607ed087c..2a63f1896b63 100644
> > --- a/arch/x86/entry/syscalls/syscall_32.tbl
> > +++ b/arch/x86/entry/syscalls/syscall_32.tbl
> > @@ -433,3 +433,4 @@
> >  425i386io_uring_setup  sys_io_uring_setup  
> > __ia32_sys_io_uring_setup
> >  426i386io_uring_enter  sys_io_uring_enter  
> > __ia32_sys_io_uring_enter
> >  427i386io_uring_register   sys_io_uring_register   
> > __ia32_sys_io_uring_register
> > +428i386pidfd_wait  sys_pidfd_wait  
> > __ia32_sys_pidfd_wait
> > diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
> > b/arch/x86/entry/syscalls/syscall_64.tbl
> > index 92ee0b4378d4..cf2e08a8053b 100644
> > --- a/arch/x86/entry/syscalls/syscall_64.tbl
> > +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> > @@ -349,6 +349,7 @@
> >  425common  io_uring_setup  __x64_sys_io_uring_setup
> >  426common  io_uring_enter  __x64_sys_io_uring_enter
> >  427common  io_uring_register   __x64_sys_io_uring_register
> > +428common  pidfd_wait  __x64_sys_pidfd_wait
> >  
> >  #
> >  # x32-specific system call numbers start at 512 to avoid cache impact
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index e446806a561f..62160970ed3f 100644
> > --- a/include/linux/syscalls.h
> > +++ b/include/linux/syscalls.h
> > @@ -988,6 +988,7 @@ asmlinkage long sys_rseq(struct rseq __user *rseq, 
> > uint32_t rseq_len,
> >  asmlinkage long sys_pidfd_send_signal(int pidfd, int sig,
> >siginfo_t __user *info,
> >unsigned int flags);
> > +asmlinkage long sys_pidfd_wait(int pidfd);
> >  
> >  /*
> >   * Architecture-specific system calls
> > diff --git a/include/uapi/asm-generic/unistd.h 
> > b/include/uapi/asm-generic/unistd.h
> > index dee7292e1df6..137aa8662230 100644
> > --- a/include/uapi/asm-generic/unistd.h
> > +++ b/include/uapi/asm-generic/unistd.h
> > @@ -832,9 +832,11 @@ __SYSCALL(__NR_io_uring_setup, sys_io_uring_setup)
> >  __SYSCALL(__NR_io_uring_enter, sys_io_uring_enter)
> >  #define __NR_io_uring_register 427
> >  __SYSCALL(__NR_io_uring_register, sys_io_uring_register)
> > +#define __NR_pidfd_wait 428
> > +__SYSCALL(__NR_pidfd_wait, sys_pidfd_wait)
> >  
> >  #undef __NR_syscalls
> > -#define __NR_syscalls 428
> > +#define __NR_syscalls 429
> >  
> >  /*
> >   * 32 bit systems traditionally used different
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index b7953934aa99..ebb550b87044 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -3550,6 +3550,68 @@ static int 
> > copy_siginfo_from_user_any(kernel_siginfo_t *kinfo, siginfo_t *info)
> > return copy_siginfo_from_user(kinfo, info);
> >  }
> >  
> > +static ssize_t pidfd_wait_read_iter(struct kiocb *iocb, struct iov_iter 
> > *to)
> > +{
> > +   /*
> > +* This is just a test string, it will contain the actual
> > +* status of the pidfd in the future.
> > +*/
> > +   char buf[] = "status";
> > +
> > +   return copy_to_iter(buf, strlen(buf)+1, to);
> > +}
> > +
> > +static const struct file_operations pidfd_wait_file_ops = {
> > +   .read_iter  = pidfd_wait_read_iter,
> > +};
> > +
> > +static struct inode *pidfd_wait_get_inode(struct super_block *sb)
> > +{
> > +   struct inode *inode = new_inode(sb);
> > +
> > +   inode->i_ino = get_next_ino();
> > +   inode_init_owner(inode, NULL, S_IFREG);
> > +
> > +   inode->i_op = _dir_inode_operations;
> > +   inode->i_fop= _wait_file_ops;
> > +
> > +   return inode;
> > +}
> > +
> > +SYSCALL_DEFINE1(pidfd_wait, int, pidfd)
> > +{
> > +   struct fd f;
> > +   struct inode *inode;
> > +   struct file *file;
> > +   int new_fd;
> > +   struct pid_namespace *pid_ns;
> > +   struct super_block *sb;
> > +   struct vfsmount *mnt;
> > +
> > +   f = fdget_raw(pidfd);
> > +   if (!f.file)
> > +   return -EBADF;
> > +
> > +   sb = file_inode(f.file)->i_sb;
> > +   pid_ns = sb->s_fs_info;
> > +
> > +   inode = pidfd_wait_get_inode(sb);
> > +
> > +   mnt = pid_ns->proc_mnt;
> > +
> > +   file = alloc_file_pseudo(inode, mnt, 

Re: v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite

[Paul Moore]

On Tue, Mar 19, 2019 at 6:16 PM Todd Kjos  wrote:
> On Tue, Mar 19, 2019 at 3:08 PM Paul Moore  wrote:
> >
> > On Tue, Mar 19, 2019 at 3:33 PM Paul Moore  wrote:
> > > On Tue, Mar 19, 2019 at 12:51 PM Todd Kjos  wrote:
> > > > Paul,
> > > >
> > > > I think this patch will fix it... can you run the selinux-testsuite
> > > > with the patch to verify? (the conditional assumed that size_t can go
> > > > negative)
> > >
> > > Building a test kernel now, I'll report back as soon as it is finished.
> >
> > Good news, the BUG_ON() panic is now gone,
>
> Great. Thanks for testing it.

Thanks for the fix :)

> > but I'm seeing a test
> > failure, although to be fair I saw some binder test failures during
> > the merge window (I generally don't worry about failures until -rc1 is
> > released).  The selinux-testsuite binder tests have been working since
> > spring 2018, but it's possible there might be a bug in the tests that
> > is just now showing up.  Have you ever looked at the selinux-testsuite
> > tests for binder?
>
> No, I didn't know they existed until yesterday. Glad to have more test
> coverage. Were they running clean on 5.0.0?

Yep.  They were added to the test suite last May and have been running
clean since then.

> Is there a public dashboard where I can take a look at those binder failures?

Not really.  I send test results to a not-yet-publicized mailing list,
but there is more detail in the GitHub issue below (my last comment
has the verbose test output):

* https://github.com/SELinuxProject/selinux-kernel/issues/46

> > * 
> > https://github.com/SELinuxProject/selinux-testsuite/tree/master/tests/binder
> >
> > > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > > > index 9a7c431469b3..bb9a661ffecc 100644
> > > > --- a/drivers/android/binder.c
> > > > +++ b/drivers/android/binder.c
> > > > @@ -2240,7 +2240,8 @@ static size_t binder_get_object(struct 
> > > > binder_proc *proc,
> > > > size_t object_size = 0;
> > > >
> > > > read_size = min_t(size_t, sizeof(*object), buffer->data_size - 
> > > > offset);
> > > > -   if (read_size < sizeof(*hdr) || !IS_ALIGNED(offset, 
> > > > sizeof(u32)))
> > > > +   if (offset > buffer->data_size || read_size < sizeof(*hdr) ||
> > > > +   !IS_ALIGNED(offset, sizeof(u32)))
> > > > return 0;
> > > > binder_alloc_copy_from_buffer(>alloc, object, buffer,
> > > >   offset, read_size);
> > > >
> > > > On Mon, Mar 18, 2019 at 4:02 PM Paul Moore  wrote:
> > > > >
> > > > > On Mon, Mar 18, 2019 at 6:51 PM Todd Kjos  wrote:
> > > > > > On Mon, Mar 18, 2019 at 2:31 PM Paul Moore  
> > > > > > wrote:
> > > > > > > Hello all.
> > > > > > >
> > > > > > > When running the selinux-testsuite (link below) against v5.1-rc1 
> > > > > > > I hit
> > > > > > > the BUG_ON() at the top of binder_alloc_do_buffer_copy() (trace
> > > > > > > below).  I'm hoping this is a known issue with a fix already in 
> > > > > > > the
> > > > > > > works?
> > > > > >
> > > > > >
> > > > > > Sadly, this is the first report of this, so no fix in flight. I'll 
> > > > > > try
> > > > > > to get a fix up in the next few days.
> > > > >
> > > > > No problem, thanks for letting me know.  If you need some testing
> > > > > help, let me know.
> >
> > --
> > paul moore
> > www.paul-moore.com



-- 
paul moore
www.paul-moore.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

[Christian Brauner]

On Mon, Mar 18, 2019 at 07:50:52PM -0400, Joel Fernandes wrote:
> On Mon, Mar 18, 2019 at 01:29:51AM +0100, Christian Brauner wrote:
> > On Sun, Mar 17, 2019 at 08:40:19AM -0700, Daniel Colascione wrote:
> > > On Sun, Mar 17, 2019 at 4:42 AM Christian Brauner  
> > > wrote:
> > > >
> > > > On Sat, Mar 16, 2019 at 09:53:06PM -0400, Joel Fernandes wrote:
> > > > > On Sat, Mar 16, 2019 at 12:37:18PM -0700, Suren Baghdasaryan wrote:
> > > > > > On Sat, Mar 16, 2019 at 11:57 AM Christian Brauner 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Sat, Mar 16, 2019 at 11:00:10AM -0700, Daniel Colascione wrote:
> > > > > > > > On Sat, Mar 16, 2019 at 10:31 AM Suren Baghdasaryan 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner 
> > > > > > > > > > wrote:
> > > > > > > > > > [..]
> > > > > > > > > > > > why do we want to add a new syscall (pidfd_wait) 
> > > > > > > > > > > > though? Why not just use
> > > > > > > > > > > > standard poll/epoll interface on the proc fd like 
> > > > > > > > > > > > Daniel was suggesting.
> > > > > > > > > > > > AFAIK, once the proc file is opened, the struct pid is 
> > > > > > > > > > > > essentially pinned
> > > > > > > > > > > > even though the proc number may be reused. Then the 
> > > > > > > > > > > > caller can just poll.
> > > > > > > > > > > > We can add a waitqueue to struct pid, and wake up any 
> > > > > > > > > > > > waiters on process
> > > > > > > > > > > > death (A quick look shows task_struct can be mapped to 
> > > > > > > > > > > > its struct pid) and
> > > > > > > > > > > > also possibly optimize it using Steve's TIF flag idea. 
> > > > > > > > > > > > No new syscall is
> > > > > > > > > > > > needed then, let me know if I missed something?
> > > > > > > > > > >
> > > > > > > > > > > Huh, I thought that Daniel was against the poll/epoll 
> > > > > > > > > > > solution?
> > > > > > > > > >
> > > > > > > > > > Hmm, going through earlier threads, I believe so now. Here 
> > > > > > > > > > was Daniel's
> > > > > > > > > > reasoning about avoiding a notification about process death 
> > > > > > > > > > through proc
> > > > > > > > > > directory fd: 
> > > > > > > > > > http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html
> > > > > > > > > >
> > > > > > > > > > May be a dedicated syscall for this would be cleaner after 
> > > > > > > > > > all.
> > > > > > > > >
> > > > > > > > > Ah, I wish I've seen that discussion before...
> > > > > > > > > syscall makes sense and it can be non-blocking and we can use
> > > > > > > > > select/poll/epoll if we use eventfd.
> > > > > > > >
> > > > > > > > Thanks for taking a look.
> > > > > > > >
> > > > > > > > > I would strongly advocate for
> > > > > > > > > non-blocking version or at least to have a non-blocking 
> > > > > > > > > option.
> > > > > > > >
> > > > > > > > Waiting for FD readiness is *already* blocking or non-blocking
> > > > > > > > according to the caller's desire --- users can pass options 
> > > > > > > > they want
> > > > > > > > to poll(2) or whatever. There's no need for any kind of special
> > > > > > > > configuration knob or non-blocking option. We already *have* a
> > > > > > > > non-blocking option that works universally for everything.
> > > > > > > >
> > > > > > > > As I mentioned in the linked thread, waiting for process exit 
> > > > > > > > should
> > > > > > > > work just like waiting for bytes to appear on a pipe. Process 
> > > > > > > > exit
> > > > > > > > status is just another blob of bytes that a process might 
> > > > > > > > receive. A
> > > > > > > > process exit handle ought to be just another information 
> > > > > > > > source. The
> > > > > > > > reason the unix process API is so awful is that for whatever 
> > > > > > > > reason
> > > > > > > > the original designers treated processes as some kind of 
> > > > > > > > special kind
> > > > > > > > of resource instead of fitting them into the otherwise 
> > > > > > > > general-purpose
> > > > > > > > unix data-handling API. Let's not repeat that mistake.
> > > > > > > >
> > > > > > > > > Something like this:
> > > > > > > > >
> > > > > > > > > evfd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> > > > > > > > > // register eventfd to receive death notification
> > > > > > > > > pidfd_wait(pid_to_kill, evfd);
> > > > > > > > > // kill the process
> > > > > > > > > pidfd_send_signal(pid_to_kill, ...)
> > > > > > > > > // tend to other things
> > > > > > > >
> > > > > > > > Now you've lost me. pidfd_wait should return a *new* FD, not 
> > > > > > > > wire up
> > > > > > > > an eventfd.
> > > > > > > >
> > > > > >
> > > > > > Ok, I probably misunderstood your post linked by Joel. I though your
> > > > > > original proposal was based on being able to poll a file under
> > > > > > /proc/pid and then you changed your mind to have a separate syscall
> > > > 

Re: v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite

[Paul Moore]

On Tue, Mar 19, 2019 at 3:33 PM Paul Moore  wrote:
> On Tue, Mar 19, 2019 at 12:51 PM Todd Kjos  wrote:
> > Paul,
> >
> > I think this patch will fix it... can you run the selinux-testsuite
> > with the patch to verify? (the conditional assumed that size_t can go
> > negative)
>
> Building a test kernel now, I'll report back as soon as it is finished.

Good news, the BUG_ON() panic is now gone, but I'm seeing a test
failure, although to be fair I saw some binder test failures during
the merge window (I generally don't worry about failures until -rc1 is
released).  The selinux-testsuite binder tests have been working since
spring 2018, but it's possible there might be a bug in the tests that
is just now showing up.  Have you ever looked at the selinux-testsuite
tests for binder?

* https://github.com/SELinuxProject/selinux-testsuite/tree/master/tests/binder

> > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > index 9a7c431469b3..bb9a661ffecc 100644
> > --- a/drivers/android/binder.c
> > +++ b/drivers/android/binder.c
> > @@ -2240,7 +2240,8 @@ static size_t binder_get_object(struct binder_proc 
> > *proc,
> > size_t object_size = 0;
> >
> > read_size = min_t(size_t, sizeof(*object), buffer->data_size - 
> > offset);
> > -   if (read_size < sizeof(*hdr) || !IS_ALIGNED(offset, sizeof(u32)))
> > +   if (offset > buffer->data_size || read_size < sizeof(*hdr) ||
> > +   !IS_ALIGNED(offset, sizeof(u32)))
> > return 0;
> > binder_alloc_copy_from_buffer(>alloc, object, buffer,
> >   offset, read_size);
> >
> > On Mon, Mar 18, 2019 at 4:02 PM Paul Moore  wrote:
> > >
> > > On Mon, Mar 18, 2019 at 6:51 PM Todd Kjos  wrote:
> > > > On Mon, Mar 18, 2019 at 2:31 PM Paul Moore  wrote:
> > > > > Hello all.
> > > > >
> > > > > When running the selinux-testsuite (link below) against v5.1-rc1 I hit
> > > > > the BUG_ON() at the top of binder_alloc_do_buffer_copy() (trace
> > > > > below).  I'm hoping this is a known issue with a fix already in the
> > > > > works?
> > > >
> > > >
> > > > Sadly, this is the first report of this, so no fix in flight. I'll try
> > > > to get a fix up in the next few days.
> > >
> > > No problem, thanks for letting me know.  If you need some testing
> > > help, let me know.

-- 
paul moore
www.paul-moore.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8192e: rtllib_rx.c remove multiple blank lines

[Dominik Adamski]

Fix checkpatch issue:
Please don't use multiple blank lines

Signed-off-by: Dominik Adamski 
---
 drivers/staging/rtl8192e/rtllib_rx.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_rx.c 
b/drivers/staging/rtl8192e/rtllib_rx.c
index debc2e40af00..6e8010591d7e 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -20,7 +20,6 @@
 
 **/
 
-
 #include 
 #include 
 #include 
@@ -162,7 +161,6 @@ rtllib_frag_cache_get(struct rtllib_device *ieee,
return skb;
 }
 
-
 /* Called only as a tasklet (software IRQ) */
 static int rtllib_frag_cache_invalidate(struct rtllib_device *ieee,
   struct rtllib_hdr_4addr *hdr)
@@ -326,7 +324,6 @@ rtllib_rx_frame_decrypt(struct rtllib_device *ieee, struct 
sk_buff *skb,
return res;
 }
 
-
 /* Called only as a tasklet (software IRQ), by rtllib_rx */
 static inline int
 rtllib_rx_frame_decrypt_msdu(struct rtllib_device *ieee, struct sk_buff *skb,
@@ -363,7 +360,6 @@ rtllib_rx_frame_decrypt_msdu(struct rtllib_device *ieee, 
struct sk_buff *skb,
return 0;
 }
 
-
 /* this function is stolen from ipw2200 driver*/
 #define IEEE_PACKET_RETRY_TIME (5*HZ)
 static int is_duplicate_packet(struct rtllib_device *ieee,
@@ -895,7 +891,6 @@ static u8 parse_subframe(struct rtllib_device *ieee, struct 
sk_buff *skb,
return rxb->nr_subframes;
 }
 
-
 static size_t rtllib_rx_get_hdrlen(struct rtllib_device *ieee,
   struct sk_buff *skb,
   struct rtllib_rx_stats *rx_stats)
@@ -1579,7 +1574,6 @@ static int rtllib_verify_qos_info(struct 
rtllib_qos_information_element
return 0;
 }
 
-
 /* Parse a QoS parameter element */
 static int rtllib_read_qos_param_element(struct rtllib_qos_parameter_info
*element_param,
@@ -1634,7 +1628,6 @@ static int rtllib_read_qos_info_element(struct 
rtllib_qos_information_element
return ret;
 }
 
-
 /* Write QoS parameters from the ac parameters. */
 static int rtllib_qos_convert_ac_to_parameters(struct 
rtllib_qos_parameter_info *param_elm,
   struct rtllib_qos_data *qos_data)
@@ -1877,7 +1870,6 @@ static void rtllib_parse_mife_generic(struct 
rtllib_device *ieee,
}
}
 
-
if (*tmp_htinfo_len == 0) {
if (info_element->len >= 4 &&
info_element->data[0] == 0x00 &&
@@ -1965,7 +1957,6 @@ static void rtllib_parse_mife_generic(struct 
rtllib_device *ieee,
info_element->data[2] == 0x96)
network->cisco_cap_exist = true;
 
-
if (info_element->len >= 3 &&
info_element->data[0] == 0x00 &&
info_element->data[1] == 0x0a &&
@@ -2175,13 +2166,11 @@ int rtllib_parse_info_param(struct rtllib_device *ieee,
 
network->dtim_data = RTLLIB_DTIM_VALID;
 
-
if (info_element->data[2] & 1)
network->dtim_data |= RTLLIB_DTIM_MBCAST;
 
offset = (info_element->data[2] >> 1)*2;
 
-
if (ieee->assoc_id < 8*offset ||
ieee->assoc_id > 8*(offset + info_element->len - 3))
break;
@@ -2236,7 +2225,6 @@ int rtllib_parse_info_param(struct rtllib_device *ieee,
 _htcap_len);
break;
 
-
case MFIE_TYPE_HT_INFO:
netdev_dbg(ieee->dev, "MFIE_TYPE_HT_INFO: %d bytes\n",
   info_element->len);
@@ -2426,7 +2414,6 @@ static inline int is_same_network(struct rtllib_network 
*src,
(dst->capability & WLAN_CAPABILITY_ESS)));
 }
 
-
 static inline void update_network(struct rtllib_device *ieee,
  struct rtllib_network *dst,
  struct rtllib_network *src)
@@ -2614,7 +2601,6 @@ static inline void rtllib_process_probe_response(
goto free_network;
}
 
-
if (!rtllib_legal_channel(ieee, network->channel))
goto free_network;
 
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: rtl8188eu: Fix potential NULL pointer dereference

[Aditya Pakki]

hwxmits is allocated via kcalloc and not checked for failure before its
dereference. The patch fixes this problem by returning an error in
rtl8723bs.

---
v1: Return error and remove print in case of failure, per Greg
Signed-off-by: Aditya Pakki 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c| 10 --
 drivers/staging/rtl8188eu/include/rtw_xmit.h |  2 +-
 drivers/staging/rtl8723bs/core/rtw_xmit.c| 14 +++---
 drivers/staging/rtl8723bs/include/rtw_xmit.h |  2 +-
 4 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 1723a47a96b4..b70a87bda6f8 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -174,7 +174,10 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, 
struct adapter *padapter)
 
pxmitpriv->free_xmit_extbuf_cnt = num_xmit_extbuf;
 
-   rtw_alloc_hwxmits(padapter);
+   res = rtw_alloc_hwxmits(padapter);
+   if (res == _FAIL)
+   goto exit;
+
rtw_init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
 
for (i = 0; i < 4; i++)
@@ -1503,7 +1506,7 @@ s32 rtw_xmit_classifier(struct adapter *padapter, struct 
xmit_frame *pxmitframe)
return res;
 }
 
-void rtw_alloc_hwxmits(struct adapter *padapter)
+s32 rtw_alloc_hwxmits(struct adapter *padapter)
 {
struct hw_xmit *hwxmits;
struct xmit_priv *pxmitpriv = >xmitpriv;
@@ -1512,6 +1515,8 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
 
pxmitpriv->hwxmits = kcalloc(pxmitpriv->hwxmit_entry,
 sizeof(struct hw_xmit), GFP_KERNEL);
+   if (!pxmitpriv->hwxmits)
+   return _FAIL;
 
hwxmits = pxmitpriv->hwxmits;
 
@@ -1519,6 +1524,7 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
hwxmits[1] .sta_queue = >vi_pending;
hwxmits[2] .sta_queue = >be_pending;
hwxmits[3] .sta_queue = >bk_pending;
+   return _SUCCESS;
 }
 
 void rtw_free_hwxmits(struct adapter *padapter)
diff --git a/drivers/staging/rtl8188eu/include/rtw_xmit.h 
b/drivers/staging/rtl8188eu/include/rtw_xmit.h
index 788f59c74ea1..ba7e15fbde72 100644
--- a/drivers/staging/rtl8188eu/include/rtw_xmit.h
+++ b/drivers/staging/rtl8188eu/include/rtw_xmit.h
@@ -336,7 +336,7 @@ s32 rtw_txframes_sta_ac_pending(struct adapter *padapter,
 void rtw_init_hwxmits(struct hw_xmit *phwxmit, int entry);
 s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct adapter *padapter);
 void _rtw_free_xmit_priv(struct xmit_priv *pxmitpriv);
-void rtw_alloc_hwxmits(struct adapter *padapter);
+s32 rtw_alloc_hwxmits(struct adapter *padapter);
 void rtw_free_hwxmits(struct adapter *padapter);
 s32 rtw_xmit(struct adapter *padapter, struct sk_buff **pkt);
 
diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c 
b/drivers/staging/rtl8723bs/core/rtw_xmit.c
index 094d61bcb469..b87f13a0b563 100644
--- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
@@ -260,7 +260,9 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct 
adapter *padapter)
}
}
 
-   rtw_alloc_hwxmits(padapter);
+   res = rtw_alloc_hwxmits(padapter);
+   if (res == _FAIL)
+   goto exit;
rtw_init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
 
for (i = 0; i < 4; i++) {
@@ -2144,7 +2146,7 @@ s32 rtw_xmit_classifier(struct adapter *padapter, struct 
xmit_frame *pxmitframe)
return res;
 }
 
-void rtw_alloc_hwxmits(struct adapter *padapter)
+s32 rtw_alloc_hwxmits(struct adapter *padapter)
 {
struct hw_xmit *hwxmits;
struct xmit_priv *pxmitpriv = >xmitpriv;
@@ -2155,10 +2157,8 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
 
pxmitpriv->hwxmits = rtw_zmalloc(sizeof(struct hw_xmit) * 
pxmitpriv->hwxmit_entry);
 
-   if (pxmitpriv->hwxmits == NULL) {
-   DBG_871X("alloc hwxmits fail!...\n");
-   return;
-   }
+   if (!pxmitpriv->hwxmits)
+   return _FAIL;
 
hwxmits = pxmitpriv->hwxmits;
 
@@ -2204,7 +2204,7 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
 
}
 
-
+   return _SUCCESS;
 }
 
 void rtw_free_hwxmits(struct adapter *padapter)
diff --git a/drivers/staging/rtl8723bs/include/rtw_xmit.h 
b/drivers/staging/rtl8723bs/include/rtw_xmit.h
index 1b38b9182b31..37f42b2f22f1 100644
--- a/drivers/staging/rtl8723bs/include/rtw_xmit.h
+++ b/drivers/staging/rtl8723bs/include/rtw_xmit.h
@@ -487,7 +487,7 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct 
adapter *padapter);
 void _rtw_free_xmit_priv (struct xmit_priv *pxmitpriv);
 
 
-void rtw_alloc_hwxmits(struct adapter *padapter);
+s32 rtw_alloc_hwxmits(struct adapter *padapter);
 void rtw_free_hwxmits(struct adapter *padapter);
 
 
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org

[PATCH v2] staging: rtlwifi: rtl8822b: fix to avoid NULL pointer dereference

[Aditya Pakki]

skb allocated via dev_alloc_skb can fail and return a NULL pointer.
This patch avoids such a scenario and returns, consistent with other
invocations.

---
v1: Patch collision with rtl_phydm.c, fix as per Greg
Signed-off-by: Aditya Pakki 
---
 drivers/staging/rtlwifi/rtl8822be/fw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtlwifi/rtl8822be/fw.c 
b/drivers/staging/rtlwifi/rtl8822be/fw.c
index f061dd1382aa..cf6b7a80b753 100644
--- a/drivers/staging/rtlwifi/rtl8822be/fw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/fw.c
@@ -743,6 +743,8 @@ void rtl8822be_set_fw_rsvdpagepkt(struct ieee80211_hw *hw, 
bool b_dl_finished)
  u1_rsvd_page_loc, 3);
 
skb = dev_alloc_skb(totalpacketlen);
+   if (!skb)
+   return;
memcpy((u8 *)skb_put(skb, totalpacketlen), _page_packet,
   totalpacketlen);
 
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: rtlwifi: Fix potential NULL pointer dereference of kzalloc

[Aditya Pakki]

phydm.internal is allocated using kzalloc which is used multiple
times without a check for NULL pointer. This patch avoids such a
scenario.

--
v1: Patch collision with different things, fix as per Greg
Signed-off-by: Aditya Pakki 
---
 drivers/staging/rtlwifi/phydm/rtl_phydm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtlwifi/phydm/rtl_phydm.c 
b/drivers/staging/rtlwifi/phydm/rtl_phydm.c
index 9930ed954abb..a7932706f286 100644
--- a/drivers/staging/rtlwifi/phydm/rtl_phydm.c
+++ b/drivers/staging/rtlwifi/phydm/rtl_phydm.c
@@ -180,6 +180,8 @@ static int rtl_phydm_init_priv(struct rtl_priv *rtlpriv,
 
rtlpriv->phydm.internal =
kzalloc(sizeof(struct phy_dm_struct), GFP_KERNEL);
+   if (!rtlpriv->phydm.internal)
+   return -ENOMEM;
 
_rtl_phydm_init_com_info(rtlpriv, ic, params);
 
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite

[Paul Moore]

On Tue, Mar 19, 2019 at 12:51 PM Todd Kjos  wrote:
> Paul,
>
> I think this patch will fix it... can you run the selinux-testsuite
> with the patch to verify? (the conditional assumed that size_t can go
> negative)

Building a test kernel now, I'll report back as soon as it is finished.

Thanks.

> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 9a7c431469b3..bb9a661ffecc 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -2240,7 +2240,8 @@ static size_t binder_get_object(struct binder_proc 
> *proc,
> size_t object_size = 0;
>
> read_size = min_t(size_t, sizeof(*object), buffer->data_size - 
> offset);
> -   if (read_size < sizeof(*hdr) || !IS_ALIGNED(offset, sizeof(u32)))
> +   if (offset > buffer->data_size || read_size < sizeof(*hdr) ||
> +   !IS_ALIGNED(offset, sizeof(u32)))
> return 0;
> binder_alloc_copy_from_buffer(>alloc, object, buffer,
>   offset, read_size);
>
> On Mon, Mar 18, 2019 at 4:02 PM Paul Moore  wrote:
> >
> > On Mon, Mar 18, 2019 at 6:51 PM Todd Kjos  wrote:
> > > On Mon, Mar 18, 2019 at 2:31 PM Paul Moore  wrote:
> > > > Hello all.
> > > >
> > > > When running the selinux-testsuite (link below) against v5.1-rc1 I hit
> > > > the BUG_ON() at the top of binder_alloc_do_buffer_copy() (trace
> > > > below).  I'm hoping this is a known issue with a fix already in the
> > > > works?
> > >
> > >
> > > Sadly, this is the first report of this, so no fix in flight. I'll try
> > > to get a fix up in the next few days.
> >
> > No problem, thanks for letting me know.  If you need some testing
> > help, let me know.
> >
> > --
> > paul moore
> > www.paul-moore.com



-- 
paul moore
www.paul-moore.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Staging status of speakup

[Adam Borowski]

On Tue, Mar 19, 2019 at 04:31:21PM +, Alan Cox wrote:
> On Sat, 16 Mar 2019 10:35:43 +0100
> Samuel Thibault  wrote:
> > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > > What kind of reproducer do you need here?  It's straightforward to
> > > reproduce in casual use, at least with a software synthesizer.  
> > 
> > we need a walk-through of the kind of operation that
> > produces the issue. It does not have to be reproducible each time it is
> > done. Perhaps (I really don't know what that bug is about actually) it
> > is a matter of putting text in the selection buffer, and try to paste it
> > 100 times, and once every 10 times it will be garbled, for instance.
> 
> paste_selection still says
> 
> /* Insert the contents of the selection buffer into the
>  * queue of the tty associated with the current console.
>  * Invoked by ioctl().
>  *
>  * Locking: called without locks. Calls the ldisc wrongly with
>  * unsafe methods,
>  */
> 
> from which I deduce that with everyone using X nobody ever bothered to
> fix it. So before you look too hard at the speakup code you might want to
> review the interaction with selection.c too.

This looks like https://bugs.debian.org/849474 which causes a lockup, and
for which Bill Allombert wrote a nice reproducer.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Staging status of speakup

[Samuel Thibault]

Alan Cox, le mar. 19 mars 2019 16:31:21 +, a ecrit:
> On Sat, 16 Mar 2019 10:35:43 +0100
> Samuel Thibault  wrote:
> > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > > Okash Khawaja  writes:  
> > > > Finally there is an issue where text in output buffer sometimes gets
> > > > garbled on SMP systems, but we can continue working on it after the
> > > > driver is moved out of staging, if that's okay. Basically we need a
> > > > reproducer of this issue.  
> > > 
> > > What kind of reproducer do you need here?  It's straightforward to
> > > reproduce in casual use, at least with a software synthesizer.  
> > 
> > The problem is that neither Okash nor I are even casual users of
> > speakup, so we need a walk-through of the kind of operation that
> > produces the issue. It does not have to be reproducible each time it is
> > done. Perhaps (I really don't know what that bug is about actually) it
> > is a matter of putting text in the selection buffer, and try to paste it
> > 100 times, and once every 10 times it will be garbled, for instance.
> 
> paste_selection still says

The issue is not actually with pasting a selection, just plain text
output from applications.

Samuel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Staging status of speakup

[Alan Cox]

On Sat, 16 Mar 2019 10:35:43 +0100
Samuel Thibault  wrote:

> Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > Okash Khawaja  writes:  
> > > Finally there is an issue where text in output buffer sometimes gets
> > > garbled on SMP systems, but we can continue working on it after the
> > > driver is moved out of staging, if that's okay. Basically we need a
> > > reproducer of this issue.  
> > 
> > What kind of reproducer do you need here?  It's straightforward to
> > reproduce in casual use, at least with a software synthesizer.  
> 
> The problem is that neither Okash nor I are even casual users of
> speakup, so we need a walk-through of the kind of operation that
> produces the issue. It does not have to be reproducible each time it is
> done. Perhaps (I really don't know what that bug is about actually) it
> is a matter of putting text in the selection buffer, and try to paste it
> 100 times, and once every 10 times it will be garbled, for instance.

paste_selection still says

/* Insert the contents of the selection buffer into the
 * queue of the tty associated with the current console.
 * Invoked by ioctl().
 *
 * Locking: called without locks. Calls the ldisc wrongly with
 * unsafe methods,
 */

from which I deduce that with everyone using X nobody ever bothered to
fix it. So before you look too hard at the speakup code you might want to
review the interaction with selection.c too.

Alan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/4] staging: comedi: ni_mio_common: use insn->n in ni_eeprom_insn_read()

[Ian Abbott]

The `insn_read` handler for the EEPROM subdevice on E-series boards
(`ni_eeprom_insn_read()`) currently ignores `insn->n` (the number of
samples to read) and assumes a single sample is to be read into
`data[0]`.  Fortunately, the Comedi core ensures that `data[]` has a
length of at least 16 so there is no problem with array bounds.

The usual Comedi convention for `insn_read` handlers is to read the same
channel `insn->n` times into successive elements of `data[]` so let's do
that.  (Each channel number corresponds to a single EEPROM address.)
Since we do not expect the EEPROM data at a particular address to change
between readings, let's just read it once and copy the value `insn->n`
times.

Also, follow the usual Comedi convention and return `insn->n` from the
handler to indicate success (although any non-negative value will do).

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/drivers/ni_mio_common.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index e008095436d7..5b397ad2a604 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -4507,9 +4507,15 @@ static int ni_eeprom_insn_read(struct comedi_device *dev,
   struct comedi_insn *insn,
   unsigned int *data)
 {
-   data[0] = ni_read_eeprom(dev, CR_CHAN(insn->chanspec));
+   unsigned int val;
+   unsigned int i;
 
-   return 1;
+   if (insn->n) {
+   val = ni_read_eeprom(dev, CR_CHAN(insn->chanspec));
+   for (i = 0; i < insn->n; i++)
+   data[i] = val;
+   }
+   return insn->n;
 }
 
 static int ni_m_series_eeprom_insn_read(struct comedi_device *dev,
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/4] staging: comedi: ni_mio_common: Use insn->n in ni_calib_insn_write()

[Ian Abbott]

The `insn_write` handler for the calibration subdevice
(`ni_calib_insn_write()`) currently ignores `insn->n` (the number of
samples to write) and assumes a single sample is to be written, but
`insn->n` could be 0, meaning no samples should be written, in which
case `data[0]` is invalid.

Change `ni_calib_insn_write()` to only write to the calibration device
if `insn->n > 0`.  There isn't much point writing all the values when
`insn->n > 1`, so just write the last one (`data[insn->n - 1]`).

Also follow the usual Comedi convention and return `insn->n` from the
handler to indicate success (although any non-negative return value will
do as far as the Comedi core is concerned).

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/drivers/ni_mio_common.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 5edf59ac6706..613b6b2abf7d 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -4394,9 +4394,13 @@ static int ni_calib_insn_write(struct comedi_device *dev,
   struct comedi_insn *insn,
   unsigned int *data)
 {
-   ni_write_caldac(dev, CR_CHAN(insn->chanspec), data[0]);
+   if (insn->n) {
+   /* only bother writing the last sample to the channel */
+   ni_write_caldac(dev, CR_CHAN(insn->chanspec),
+   data[insn->n - 1]);
+   }
 
-   return 1;
+   return insn->n;
 }
 
 static int ni_calib_insn_read(struct comedi_device *dev,
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/4] staging: comedi: ni_mio_common: Don't assume insn->n is 1

[Ian Abbott]

For insn_read and insn_write handlers for the EEPROM and calibration
subdevices currently assume that insn->n is 1 and access data[0] without
checking insn->n.  data[0] exists because the Comedi core ensures it,
but in the case of the insn_write handler it will contain some random,
uninitialized value.

These patches change the handlers to follow the usual Comedi
conventions.

1) staging: comedi: ni_mio_common: Use insn->n in ni_calib_insn_write()
2) staging: comedi: ni_mio_common: use insn->n in ni_calib_insn_read()
3) staging: comedi: ni_mio_common: use insn->n in ni_eeprom_insn_read()
4) staging: comedi: ni_mio_common: use insn->n in
   ni_m_series_eeprom_insn_read()

 drivers/staging/comedi/drivers/ni_mio_common.c | 30 +++---
 1 file changed, 22 insertions(+), 8 deletions(-)

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/4] staging: comedi: ni_mio_common: use insn->n in ni_calib_insn_read()

[Ian Abbott]

The `insn_read` handler for the calibration subdevice
(`ni_calib_insn_read()`) currently ignores `insn->n` (the number of
samples to read) and assumes a single sample is to be read into
`data[0]`.  Fortunately, the Comedi core ensures that `data[]` has a
length of at least 16, so there is no problem with array bounds.

The usual Comedi convention for `insn_read` handlers is to read the same
channel `insn->n` times into successive elements of `data[]`, so let's
do that.

Also, follow the usual Comedi convention and return `insn->n` from the
handler to indicate success (although any non-negative value will do).

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/drivers/ni_mio_common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 613b6b2abf7d..e008095436d7 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -4409,10 +4409,12 @@ static int ni_calib_insn_read(struct comedi_device *dev,
  unsigned int *data)
 {
struct ni_private *devpriv = dev->private;
+   unsigned int i;
 
-   data[0] = devpriv->caldacs[CR_CHAN(insn->chanspec)];
+   for (i = 0; i < insn->n; i++)
+   data[0] = devpriv->caldacs[CR_CHAN(insn->chanspec)];
 
-   return 1;
+   return insn->n;
 }
 
 static void caldac_setup(struct comedi_device *dev, struct comedi_subdevice *s)
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/4] staging: comedi: ni_mio_common: use insn->n in ni_m_series_eeprom_insn_read()

[Ian Abbott]

The `insn_read` handler for the EEPROM subdevice on M-series boards
(`ni_m_series_eeprom_insn_read()`) currently ignores `insn->n` (the
number of samples to read) and assumes a single sample is to be read
into `data[0]`.  Fortunately, the Comedi core ensures that `data[]` has
a length of at least 16 so there is no problem with array bounds.

The usual Comedi convention for `insn_read` handlers is to read the same
channel `insn->n` times into successive elements of `data[]` so let's do
that.  (Each channel corresponds to a single EEPROM address.)  In this
case, the data value comes from a local copy of the EEPROM contents.

Also, follow the usual Comedi convention and return `insn->n` from the
handler to indicate success (although any non-negative value will do).

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/drivers/ni_mio_common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 5b397ad2a604..5eef1a63e3eb 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -4524,10 +4524,12 @@ static int ni_m_series_eeprom_insn_read(struct 
comedi_device *dev,
unsigned int *data)
 {
struct ni_private *devpriv = dev->private;
+   unsigned int i;
 
-   data[0] = devpriv->eeprom_buffer[CR_CHAN(insn->chanspec)];
+   for (i = 0; i < insn->n; i++)
+   data[i] = devpriv->eeprom_buffer[CR_CHAN(insn->chanspec)];
 
-   return 1;
+   return insn->n;
 }
 
 static unsigned int ni_old_get_pfi_routing(struct comedi_device *dev,
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite

[Todd Kjos]

Paul,

I think this patch will fix it... can you run the selinux-testsuite
with the patch to verify? (the conditional assumed that size_t can go
negative)

Thanks,

-Todd


diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 9a7c431469b3..bb9a661ffecc 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2240,7 +2240,8 @@ static size_t binder_get_object(struct binder_proc *proc,
size_t object_size = 0;

read_size = min_t(size_t, sizeof(*object), buffer->data_size - offset);
-   if (read_size < sizeof(*hdr) || !IS_ALIGNED(offset, sizeof(u32)))
+   if (offset > buffer->data_size || read_size < sizeof(*hdr) ||
+   !IS_ALIGNED(offset, sizeof(u32)))
return 0;
binder_alloc_copy_from_buffer(>alloc, object, buffer,
  offset, read_size);

On Mon, Mar 18, 2019 at 4:02 PM Paul Moore  wrote:
>
> On Mon, Mar 18, 2019 at 6:51 PM Todd Kjos  wrote:
> > On Mon, Mar 18, 2019 at 2:31 PM Paul Moore  wrote:
> > > Hello all.
> > >
> > > When running the selinux-testsuite (link below) against v5.1-rc1 I hit
> > > the BUG_ON() at the top of binder_alloc_do_buffer_copy() (trace
> > > below).  I'm hoping this is a known issue with a fix already in the
> > > works?
> >
> >
> > Sadly, this is the first report of this, so no fix in flight. I'll try
> > to get a fix up in the next few days.
>
> No problem, thanks for letting me know.  If you need some testing
> help, let me know.
>
> --
> paul moore
> www.paul-moore.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/1] staging: media: imx: imx7-mipi-csis: simplify getting .driver_data

[Wolfram Sang]

We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy.

 drivers/staging/media/imx/imx7-mipi-csis.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c 
b/drivers/staging/media/imx/imx7-mipi-csis.c
index 2ddcc42ab8ff..44569c63e4de 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -1039,8 +1039,7 @@ static int mipi_csis_probe(struct platform_device *pdev)
 
 static int mipi_csis_pm_suspend(struct device *dev, bool runtime)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct v4l2_subdev *mipi_sd = platform_get_drvdata(pdev);
+   struct v4l2_subdev *mipi_sd = dev_get_drvdata(dev);
struct csi_state *state = mipi_sd_to_csis_state(mipi_sd);
int ret = 0;
 
@@ -1064,8 +1063,7 @@ static int mipi_csis_pm_suspend(struct device *dev, bool 
runtime)
 
 static int mipi_csis_pm_resume(struct device *dev, bool runtime)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct v4l2_subdev *mipi_sd = platform_get_drvdata(pdev);
+   struct v4l2_subdev *mipi_sd = dev_get_drvdata(dev);
struct csi_state *state = mipi_sd_to_csis_state(mipi_sd);
int ret = 0;
 
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] Fix comment style in header and functions

[Greg KH]

On Tue, Mar 19, 2019 at 12:47:02PM -0300, Ariel Torti wrote:
> From: Ariel Torti 
> 
> Signed-off-by: Ariel Torti 
> ---
>  drivers/staging/rtl8723bs/core/rtw_io.c | 50 
> +++--
>  1 file changed, 23 insertions(+), 27 deletions(-)


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

Same for all patches in this series, please fix up.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/4] Fix lines longer than 80 chars

[Ariel Torti]

From: Ariel Torti 

Signed-off-by: Ariel Torti 
---
 drivers/staging/rtl8723bs/core/rtw_io.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_io.c 
b/drivers/staging/rtl8723bs/core/rtw_io.c
index 0470074..480227a 100644
--- a/drivers/staging/rtl8723bs/core/rtw_io.c
+++ b/drivers/staging/rtl8723bs/core/rtw_io.c
@@ -121,14 +121,17 @@ u8 _rtw_sd_f0_read8(struct adapter *adapter, u32 addr)
if (_sd_f0_read8)
r_val = _sd_f0_read8(pintfhdl, addr);
else
-   DBG_871X_LEVEL(_drv_warning_, FUNC_ADPT_FMT" _sd_f0_read8 
callback is NULL\n", FUNC_ADPT_ARG(adapter));
+   DBG_871X_LEVEL(_drv_warning_, FUNC_ADPT_FMT
+  " _sd_f0_read8 callback is NULL\n",
+  FUNC_ADPT_ARG(adapter));
 
return r_val;
 }
 
 u32 _rtw_write_port(struct adapter *adapter, u32 addr, u32 cnt, u8 *pmem)
 {
-   u32 (*_write_port)(struct intf_hdl *pintfhdl, u32 addr, u32 cnt, u8 
*pmem);
+   u32 (*_write_port)(struct intf_hdl *pintfhdl, u32 addr, u32 cnt,
+  u8 *pmem);
struct io_priv *pio_priv = >iopriv;
struct  intf_hdl*pintfhdl = &(pio_priv->intf);
u32 ret = _SUCCESS;
@@ -140,7 +143,9 @@ u32 _rtw_write_port(struct adapter *adapter, u32 addr, u32 
cnt, u8 *pmem)
return ret;
 }
 
-int rtw_init_io_priv(struct adapter *padapter, void (*set_intf_ops)(struct 
adapter *padapter, struct _io_ops *pops))
+int rtw_init_io_priv(struct adapter *padapter,
+void (*set_intf_ops)(struct adapter *padapter,
+ struct _io_ops *pops))
 {
struct io_priv *piopriv = >iopriv;
struct intf_hdl *pintf = >intf;
@@ -170,7 +175,8 @@ int rtw_inc_and_chk_continual_io_error(struct dvobj_priv 
*dvobj)
int value = atomic_inc_return(>continual_io_error);
 
if (value > MAX_CONTINUAL_IO_ERR) {
-   DBG_871X("[dvobj:%p][ERROR] continual_io_error:%d > %d\n", 
dvobj, value, MAX_CONTINUAL_IO_ERR);
+   DBG_871X("[dvobj:%p][ERROR] continual_io_error:%d > %d\n",
+dvobj, value, MAX_CONTINUAL_IO_ERR);
ret = true;
}
return ret;
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/4] Add blank lines at the end of file and after functions

[Ariel Torti]

From: Ariel Torti 

Signed-off-by: Ariel Torti 
---
 drivers/staging/rtl8723bs/core/rtw_io.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/rtl8723bs/core/rtw_io.c 
b/drivers/staging/rtl8723bs/core/rtw_io.c
index fc0fd245..0470074 100644
--- a/drivers/staging/rtl8723bs/core/rtw_io.c
+++ b/drivers/staging/rtl8723bs/core/rtw_io.c
@@ -81,6 +81,7 @@ int _rtw_write8(struct adapter *adapter, u32 addr, u8 val)
 
return RTW_STATUS_CODE(ret);
 }
+
 int _rtw_write16(struct adapter *adapter, u32 addr, u16 val)
 {
struct io_priv *pio_priv = >iopriv;
@@ -93,6 +94,7 @@ int _rtw_write16(struct adapter *adapter, u32 addr, u16 val)
ret = _write16(pintfhdl, addr, val);
return RTW_STATUS_CODE(ret);
 }
+
 int _rtw_write32(struct adapter *adapter, u32 addr, u32 val)
 {
struct io_priv *pio_priv = >iopriv;
@@ -166,6 +168,7 @@ int rtw_inc_and_chk_continual_io_error(struct dvobj_priv 
*dvobj)
 {
int ret = false;
int value = atomic_inc_return(>continual_io_error);
+
if (value > MAX_CONTINUAL_IO_ERR) {
DBG_871X("[dvobj:%p][ERROR] continual_io_error:%d > %d\n", 
dvobj, value, MAX_CONTINUAL_IO_ERR);
ret = true;
@@ -180,3 +183,4 @@ void rtw_reset_continual_io_error(struct dvobj_priv *dvobj)
 {
atomic_set(>continual_io_error, 0);
 }
+
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/4] Remove commented code

[Ariel Torti]

From: Ariel Torti 

Signed-off-by: Ariel Torti 
---
 drivers/staging/rtl8723bs/core/rtw_io.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_io.c 
b/drivers/staging/rtl8723bs/core/rtw_io.c
index 16f7b34..fc0fd245 100644
--- a/drivers/staging/rtl8723bs/core/rtw_io.c
+++ b/drivers/staging/rtl8723bs/core/rtw_io.c
@@ -32,7 +32,6 @@
 u8 _rtw_read8(struct adapter *adapter, u32 addr)
 {
u8 r_val;
-   /* struct   io_queue*pio_queue = (struct io_queue 
*)adapter->pio_queue; */
struct io_priv *pio_priv = >iopriv;
struct  intf_hdl*pintfhdl = &(pio_priv->intf);
u8 (*_read8)(struct intf_hdl *pintfhdl, u32 addr);
@@ -46,7 +45,6 @@ u8 _rtw_read8(struct adapter *adapter, u32 addr)
 u16 _rtw_read16(struct adapter *adapter, u32 addr)
 {
u16 r_val;
-   /* struct   io_queue*pio_queue = (struct io_queue 
*)adapter->pio_queue; */
struct io_priv *pio_priv = >iopriv;
struct  intf_hdl*pintfhdl = &(pio_priv->intf);
u16 (*_read16)(struct intf_hdl *pintfhdl, u32 addr);
@@ -60,7 +58,6 @@ u16 _rtw_read16(struct adapter *adapter, u32 addr)
 u32 _rtw_read32(struct adapter *adapter, u32 addr)
 {
u32 r_val;
-   /* struct   io_queue*pio_queue = (struct io_queue 
*)adapter->pio_queue; */
struct io_priv *pio_priv = >iopriv;
struct  intf_hdl*pintfhdl = &(pio_priv->intf);
u32 (*_read32)(struct intf_hdl *pintfhdl, u32 addr);
@@ -69,12 +66,10 @@ u32 _rtw_read32(struct adapter *adapter, u32 addr)
 
r_val = _read32(pintfhdl, addr);
return rtw_le32_to_cpu(r_val);
-
 }
 
 int _rtw_write8(struct adapter *adapter, u32 addr, u8 val)
 {
-   /* struct   io_queue*pio_queue = (struct io_queue 
*)adapter->pio_queue; */
struct io_priv *pio_priv = >iopriv;
struct  intf_hdl*pintfhdl = &(pio_priv->intf);
int (*_write8)(struct intf_hdl *pintfhdl, u32 addr, u8 val);
@@ -88,7 +83,6 @@ int _rtw_write8(struct adapter *adapter, u32 addr, u8 val)
 }
 int _rtw_write16(struct adapter *adapter, u32 addr, u16 val)
 {
-   /* struct   io_queue*pio_queue = (struct io_queue 
*)adapter->pio_queue; */
struct io_priv *pio_priv = >iopriv;
struct  intf_hdl*pintfhdl = &(pio_priv->intf);
int (*_write16)(struct intf_hdl *pintfhdl, u32 addr, u16 val);
@@ -101,7 +95,6 @@ int _rtw_write16(struct adapter *adapter, u32 addr, u16 val)
 }
 int _rtw_write32(struct adapter *adapter, u32 addr, u32 val)
 {
-   /* struct   io_queue*pio_queue = (struct io_queue 
*)adapter->pio_queue; */
struct io_priv *pio_priv = >iopriv;
struct  intf_hdl*pintfhdl = &(pio_priv->intf);
int (*_write32)(struct intf_hdl *pintfhdl, u32 addr, u32 val);
@@ -176,8 +169,6 @@ int rtw_inc_and_chk_continual_io_error(struct dvobj_priv 
*dvobj)
if (value > MAX_CONTINUAL_IO_ERR) {
DBG_871X("[dvobj:%p][ERROR] continual_io_error:%d > %d\n", 
dvobj, value, MAX_CONTINUAL_IO_ERR);
ret = true;
-   } else {
-   /* DBG_871X("[dvobj:%p] continual_io_error:%d\n", dvobj, 
value); */
}
return ret;
 }
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/4] Fix comment style in header and functions

[Ariel Torti]

From: Ariel Torti 

Signed-off-by: Ariel Torti 
---
 drivers/staging/rtl8723bs/core/rtw_io.c | 50 +++--
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_io.c 
b/drivers/staging/rtl8723bs/core/rtw_io.c
index d341069..16f7b34 100644
--- a/drivers/staging/rtl8723bs/core/rtw_io.c
+++ b/drivers/staging/rtl8723bs/core/rtw_io.c
@@ -3,27 +3,21 @@
  *
  * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
  *
- 
**/
-/*
-
-The purpose of rtw_io.c
-
-a. provides the API
-
-b. provides the protocol engine
-
-c. provides the software interface between caller and the hardware interface
-
-
-Compiler Flag Option:
-
-1. CONFIG_SDIO_HCI:
-a. USE_SYNC_IRP:  Only sync operations are provided.
-b. USE_ASYNC_IRP:Both sync/async operations are provided.
-
-jack...@realtek.com.tw
-
-*/
+ **
+ *
+ * The purpose of rtw_io.c
+ * - Provides the API
+ * - Provides the protocol engine
+ * - Provides the software interface between caller and the hardware interface
+ *
+ *
+ * Compiler Flag Option:
+ * 1. CONFIG_SDIO_HCI:
+ *   a. USE_SYNC_IRP:  Only sync operations are provided.
+ *   b. USE_ASYNC_IRP: Both sync/async operations are provided.
+ *
+ * jack...@realtek.com.tw
+ */
 
 #define _RTW_IO_C_
 
@@ -169,10 +163,12 @@ int rtw_init_io_priv(struct adapter *padapter, void 
(*set_intf_ops)(struct adapt
 }
 
 /*
-* Increase and check if the continual_io_error of this @param dvobjprive is 
larger than MAX_CONTINUAL_IO_ERR
-* @return true:
-* @return false:
-*/
+ * Increase and check if the continual_io_error of this @param dvobjprive
+ * is larger than MAX_CONTINUAL_IO_ERR
+ *
+ * @return true:
+ * @return false:
+ */
 int rtw_inc_and_chk_continual_io_error(struct dvobj_priv *dvobj)
 {
int ret = false;
@@ -187,8 +183,8 @@ int rtw_inc_and_chk_continual_io_error(struct dvobj_priv 
*dvobj)
 }
 
 /*
-* Set the continual_io_error of this @param dvobjprive to 0
-*/
+ * Set the continual_io_error of this @param dvobjprive to 0
+ */
 void rtw_reset_continual_io_error(struct dvobj_priv *dvobj)
 {
atomic_set(>continual_io_error, 0);
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/4] Clean up comments and code

[Ariel Torti]

From: Ariel Torti 

Patches cleaning up comments and code

Ariel Torti (4):
  Fix comment style in header and functions
  Remove commented code
  Add blank lines at the end of file and after functions
  Fix lines longer than 80 chars

 drivers/staging/rtl8723bs/core/rtw_io.c | 77 -
 1 file changed, 37 insertions(+), 40 deletions(-)

--
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

hello dear

[mrsaishagaddafi]

Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh,
hello dear
I came across your contact during my private search. Mrs Aisha Al-
Qaddafi is my name, the only daughter of late Libyan president, am a 
single Mother and a Widow with three Children.I have funds the sum of 
$27.5 million USD for investment, I am interested in you for investment 
project assistance in your country,because of my current refugee 
status, i shall compensate you 30% of the total sum after the funds are 
transfer into your account,I am willing to negotiate 
investment/business profit sharing ratio with you base on the future 
investment earning profits.
Reply me urgent for more details
Mrs Aisha Al-Qaddafi










___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] staging: erofs: introduce erofs_page_is_managed()

[Gao Xiang]

1) In order to clean up unnecessary
   page->mapping == MNGD_MAPPING(sbi) wrapped by #ifdefs;

2) Needed by "staging: erofs: support IO read error injection".

Signed-off-by: Gao Xiang 
---
 drivers/staging/erofs/internal.h  |  7 +++
 drivers/staging/erofs/unzip_vle.c | 31 +--
 2 files changed, 16 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index e3bfde00c7d2..ba1d86f3470e 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -268,8 +268,15 @@ int erofs_try_to_free_cached_page(struct address_space 
*mapping,
  struct page *page);
 
 #define MNGD_MAPPING(sbi)  ((sbi)->managed_cache->i_mapping)
+static inline bool erofs_page_is_managed(const struct erofs_sb_info *sbi,
+struct page *page)
+{
+   return page->mapping == MNGD_MAPPING(sbi);
+}
 #else
 #define MNGD_MAPPING(sbi)  (NULL)
+static inline bool erofs_page_is_managed(const struct erofs_sb_info *sbi,
+struct page *page) { return false; }
 #endif
 
 #define DEFAULT_MAX_SYNC_DECOMPRESS_PAGES  3
diff --git a/drivers/staging/erofs/unzip_vle.c 
b/drivers/staging/erofs/unzip_vle.c
index 3416d3f10324..d05fed4f8013 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -844,11 +844,9 @@ static void z_erofs_vle_unzip_kickoff(void *ptr, int bios)
 static inline void z_erofs_vle_read_endio(struct bio *bio)
 {
const blk_status_t err = bio->bi_status;
+   struct erofs_sb_info *sbi = NULL;
unsigned int i;
struct bio_vec *bvec;
-#ifdef EROFS_FS_HAS_MANAGED_CACHE
-   struct address_space *mc = NULL;
-#endif
struct bvec_iter_all iter_all;
 
bio_for_each_segment_all(bvec, bio, i, iter_all) {
@@ -858,20 +856,12 @@ static inline void z_erofs_vle_read_endio(struct bio *bio)
DBG_BUGON(PageUptodate(page));
DBG_BUGON(!page->mapping);
 
-#ifdef EROFS_FS_HAS_MANAGED_CACHE
-   if (unlikely(!mc && !z_erofs_is_stagingpage(page))) {
-   struct inode *const inode = page->mapping->host;
-   struct super_block *const sb = inode->i_sb;
+   if (unlikely(!sbi && !z_erofs_is_stagingpage(page)))
+   sbi = EROFS_SB(page->mapping->host->i_sb);
 
-   mc = MNGD_MAPPING(EROFS_SB(sb));
-   }
-
-   /*
-* If mc has not gotten, it equals NULL,
-* however, page->mapping never be NULL if working properly.
-*/
-   cachemngd = (page->mapping == mc);
-#endif
+   /* sbi should already be gotten if the page is managed */
+   if (sbi)
+   cachemngd = erofs_page_is_managed(sbi, page);
 
if (unlikely(err))
SetPageError(page);
@@ -983,13 +973,11 @@ static int z_erofs_vle_unzip(struct super_block *sb,
DBG_BUGON(!page->mapping);
 
if (!z_erofs_is_stagingpage(page)) {
-#ifdef EROFS_FS_HAS_MANAGED_CACHE
-   if (page->mapping == MNGD_MAPPING(sbi)) {
+   if (erofs_page_is_managed(sbi, page)) {
if (unlikely(!PageUptodate(page)))
err = -EIO;
continue;
}
-#endif
 
/*
 * only if non-head page can be selected
@@ -1054,10 +1042,9 @@ static int z_erofs_vle_unzip(struct super_block *sb,
for (i = 0; i < clusterpages; ++i) {
page = compressed_pages[i];
 
-#ifdef EROFS_FS_HAS_MANAGED_CACHE
-   if (page->mapping == MNGD_MAPPING(sbi))
+   if (erofs_page_is_managed(sbi, page))
continue;
-#endif
+
/* recycle all individual staging pages */
(void)z_erofs_gather_if_stagingpage(page_pool, page);
 
-- 
2.12.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] staging: erofs: fix error handling when failed to read compresssed data

[Gao Xiang]

Complete read error handling paths for all three kinds of
compressed pages:

 1) For cache-managed pages, PG_uptodate will be checked since
read_endio will unlock and SetPageUptodate for these pages;

 2) For inplaced pages, read_endio cannot SetPageUptodate directly
since it should be used to mark the final decompressed data,
PG_error will be set with page locked for IO error instead;

 3) For staging pages, PG_error is used, which is similar to
what we do for inplaced pages.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
---

This series focus on fixing error handling when failed to read
compresssed data due to previous incomplete paths.

In addition, the last 2 patches add IO error fault injection
for reading paths, which I have used to test the first patch as well.

Thanks,
Gao Xiang

 drivers/staging/erofs/unzip_vle.c | 41 ++-
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/erofs/unzip_vle.c 
b/drivers/staging/erofs/unzip_vle.c
index 8715bc50e09c..3416d3f10324 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -972,6 +972,7 @@ static int z_erofs_vle_unzip(struct super_block *sb,
overlapped = false;
compressed_pages = grp->compressed_pages;
 
+   err = 0;
for (i = 0; i < clusterpages; ++i) {
unsigned int pagenr;
 
@@ -981,26 +982,39 @@ static int z_erofs_vle_unzip(struct super_block *sb,
DBG_BUGON(!page);
DBG_BUGON(!page->mapping);
 
-   if (z_erofs_is_stagingpage(page))
-   continue;
+   if (!z_erofs_is_stagingpage(page)) {
 #ifdef EROFS_FS_HAS_MANAGED_CACHE
-   if (page->mapping == MNGD_MAPPING(sbi)) {
-   DBG_BUGON(!PageUptodate(page));
-   continue;
-   }
+   if (page->mapping == MNGD_MAPPING(sbi)) {
+   if (unlikely(!PageUptodate(page)))
+   err = -EIO;
+   continue;
+   }
 #endif
 
-   /* only non-head page could be reused as a compressed page */
-   pagenr = z_erofs_onlinepage_index(page);
+   /*
+* only if non-head page can be selected
+* for inplace decompression
+*/
+   pagenr = z_erofs_onlinepage_index(page);
 
-   DBG_BUGON(pagenr >= nr_pages);
-   DBG_BUGON(pages[pagenr]);
-   ++sparsemem_pages;
-   pages[pagenr] = page;
+   DBG_BUGON(pagenr >= nr_pages);
+   DBG_BUGON(pages[pagenr]);
+   ++sparsemem_pages;
+   pages[pagenr] = page;
+
+   overlapped = true;
+   }
 
-   overlapped = true;
+   /* PG_error needs checking for inplaced and staging pages */
+   if (unlikely(PageError(page))) {
+   DBG_BUGON(PageUptodate(page));
+   err = -EIO;
+   }
}
 
+   if (unlikely(err))
+   goto out;
+
llen = (nr_pages << PAGE_SHIFT) - work->pageofs;
 
if (z_erofs_vle_workgrp_fmt(grp) == Z_EROFS_VLE_WORKGRP_FMT_PLAIN) {
@@ -1194,6 +1208,7 @@ pickup_page_for_submission(struct z_erofs_vle_workgroup 
*grp,
if (page->mapping == mc) {
WRITE_ONCE(grp->compressed_pages[nr], page);
 
+   ClearPageError(page);
if (!PagePrivate(page)) {
/*
 * impossible to be !PagePrivate(page) for
-- 
2.12.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/3] staging: erofs: support IO read error injection

[Gao Xiang]

Used to simulate disk IO read error for testing fatal
error tolerance.

Here are the details,
1) use bio->bi_private to indicate super_block
   for non-compressed bios since some (mainly meta)
   pages can be of the corresponding bdev inode;
2) get super_block dynamically for compressed bios,
   therefore it could not inject bios full of staging
   pages, yet it doesn't affect the normal usage.

Signed-off-by: Gao Xiang 
---
 drivers/staging/erofs/Documentation/filesystems/erofs.txt |  1 +
 drivers/staging/erofs/data.c  | 10 +-
 drivers/staging/erofs/internal.h  |  3 ++-
 drivers/staging/erofs/super.c |  3 ++-
 drivers/staging/erofs/unzip_vle.c | 10 --
 5 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/erofs/Documentation/filesystems/erofs.txt 
b/drivers/staging/erofs/Documentation/filesystems/erofs.txt
index 961ec4da7705..74cf84ac48a3 100644
--- a/drivers/staging/erofs/Documentation/filesystems/erofs.txt
+++ b/drivers/staging/erofs/Documentation/filesystems/erofs.txt
@@ -60,6 +60,7 @@ fault_injection=%d Enable fault injection in all 
supported types with
specified injection rate. Supported injection type:
Type_NameType_Value
FAULT_KMALLOC0x1
+   FAULT_READ_IO0x2
 (no)user_xattr Setup Extended User Attributes. Note: xattr is enabled
by default if CONFIG_EROFS_FS_XATTR is selected.
 (no)aclSetup POSIX Access Control List. Note: acl is enabled
diff --git a/drivers/staging/erofs/data.c b/drivers/staging/erofs/data.c
index 526e0dbea5b5..16302ee54261 100644
--- a/drivers/staging/erofs/data.c
+++ b/drivers/staging/erofs/data.c
@@ -17,11 +17,17 @@
 
 static inline void read_endio(struct bio *bio)
 {
+   struct super_block *const sb = bio->bi_private;
int i;
struct bio_vec *bvec;
-   const blk_status_t err = bio->bi_status;
+   blk_status_t err = bio->bi_status;
struct bvec_iter_all iter_all;
 
+   if (time_to_inject(EROFS_SB(sb), FAULT_READ_IO)) {
+   erofs_show_injection_info(FAULT_READ_IO);
+   err = BLK_STS_IOERR;
+   }
+
bio_for_each_segment_all(bvec, bio, i, iter_all) {
struct page *page = bvec->bv_page;
 
@@ -69,6 +75,7 @@ struct page *__erofs_get_meta_page(struct super_block *sb,
err = PTR_ERR(bio);
goto err_out;
}
+   bio->bi_private = sb;
 
err = bio_add_page(bio, page, PAGE_SIZE, 0);
if (unlikely(err != PAGE_SIZE)) {
@@ -288,6 +295,7 @@ static inline struct bio *erofs_read_raw_page(struct bio 
*bio,
bio = NULL;
goto err_out;
}
+   bio->bi_private = inode->i_sb;
}
 
err = bio_add_page(bio, page, PAGE_SIZE, 0);
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index ba1d86f3470e..5d7addd9cff0 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -44,11 +44,12 @@
 
 enum {
FAULT_KMALLOC,
+   FAULT_READ_IO,
FAULT_MAX,
 };
 
 #ifdef CONFIG_EROFS_FAULT_INJECTION
-extern char *erofs_fault_name[FAULT_MAX];
+extern const char *erofs_fault_name[FAULT_MAX];
 #define IS_FAULT_SET(fi, type) ((fi)->inject_type & (1 << (type)))
 
 struct erofs_fault_info {
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 15c784fba879..ce025e6e4399 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -141,8 +141,9 @@ static int superblock_read(struct super_block *sb)
 }
 
 #ifdef CONFIG_EROFS_FAULT_INJECTION
-char *erofs_fault_name[FAULT_MAX] = {
+const char *erofs_fault_name[FAULT_MAX] = {
[FAULT_KMALLOC] = "kmalloc",
+   [FAULT_READ_IO] = "read IO error",
 };
 
 static void __erofs_build_fault_attr(struct erofs_sb_info *sbi,
diff --git a/drivers/staging/erofs/unzip_vle.c 
b/drivers/staging/erofs/unzip_vle.c
index d05fed4f8013..9fabdf596438 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -843,8 +843,8 @@ static void z_erofs_vle_unzip_kickoff(void *ptr, int bios)
 
 static inline void z_erofs_vle_read_endio(struct bio *bio)
 {
-   const blk_status_t err = bio->bi_status;
struct erofs_sb_info *sbi = NULL;
+   blk_status_t err = bio->bi_status;
unsigned int i;
struct bio_vec *bvec;
struct bvec_iter_all iter_all;
@@ -856,9 +856,15 @@ static inline void z_erofs_vle_read_endio(struct bio *bio)
DBG_BUGON(PageUptodate(page));
DBG_BUGON(!page->mapping);
 
-   if (unlikely(!sbi && !z_erofs_is_stagingpage(page)))
+   

Re: [PATCH] staging: ks7010: remove redundant auth_type check

[Colin Ian King]

On 19/03/2019 13:29, Greg Kroah-Hartman wrote:
> On Mon, Mar 18, 2019 at 09:32:59PM +, Jeremy Sowden wrote:
>> On 2019-03-18, at 10:57:49 +, Colin King wrote:
>>> The range check on auth_type is redundant as there is a prior
>>> check on the auth_type values and the only way the block is entered
>>> is if auth_type is one of TYPE_PMK1, TYPE_GMK1 and TYPE_GMK1.
>>
>> "... and TYPE_GMK2."
> 
> I'll go edit that, thanks.
> 
> greg k-h
> 
Thanks for fixing my typo.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: fix parenthesis alignment

[Gao Xiang]

Hi Greg,

On 2019/3/19 21:28, Greg KH wrote:
> On Mon, Mar 18, 2019 at 08:58:41PM -0300, Julian Merida wrote:
>> Fix all checkpatch issues: "CHECK: Alignment should match open parenthesis"
>>
>> Signed-off-by: Julian Merida 
>> Reviewed-by: Gao Xiang 
> 
> Was this really reviewed by Gao?  Offline or on-list?  I missed it if it
> was on-list :(

Yes, I was reviewed on the first version...

He didn't cc you and staging mailing list...
https://lists.ozlabs.org/pipermail/linux-erofs/2019-March/001486.html

It seems no logic change and doing a lot of fixes...

Thanks,
Gao Xiang

> 
> thanks,
> 
> greg k-h
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: ks7010: remove redundant auth_type check

[Greg Kroah-Hartman]

On Mon, Mar 18, 2019 at 09:32:59PM +, Jeremy Sowden wrote:
> On 2019-03-18, at 10:57:49 +, Colin King wrote:
> > The range check on auth_type is redundant as there is a prior
> > check on the auth_type values and the only way the block is entered
> > is if auth_type is one of TYPE_PMK1, TYPE_GMK1 and TYPE_GMK1.
> 
> "... and TYPE_GMK2."

I'll go edit that, thanks.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: fix parenthesis alignment

[Greg KH]

On Mon, Mar 18, 2019 at 08:58:41PM -0300, Julian Merida wrote:
> Fix all checkpatch issues: "CHECK: Alignment should match open parenthesis"
> 
> Signed-off-by: Julian Merida 
> Reviewed-by: Gao Xiang 

Was this really reviewed by Gao?  Offline or on-list?  I missed it if it
was on-list :(

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: emxx_udc: fix various function invocations indentation issues

[Greg Kroah-Hartman]

On Tue, Mar 19, 2019 at 12:02:13AM +0100, Emiliano Ingrassia wrote:
> Fix various warnings and checks issued by checkpatch.pl.

You need to be very specific as to what exactly you are doing here.
"various" is not specific :)

Also, please break up the patch into a patch series, each patch only
doing one "type" of thing to do the driver at one time.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: custom driver adding into yocto

[Greg KH]

On Tue, Mar 19, 2019 at 12:36:10PM +0530, sateesh m wrote:
> Hi Sir,
> 
>I am trying to add my own custom driver inside the yocto. how
> can I add driver and how to add already available driver .can you please
> share readme file. Thanking you in advance.

Please read the Yocto documentation, and if you have further questions
about it, contact the yocto developers.

good luck!

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[driver-core:debugfs_cleanup 57/57] net/ceph/debugfs.c:459:9: warning: 'return' with a value, in function returning void

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
debugfs_cleanup
head:   6e9f7c08eb403975521108d1f10b77f8990cfe0c
commit: 6e9f7c08eb403975521108d1f10b77f8990cfe0c [57/57] ceph: fix changelog
config: x86_64-randconfig-u0-03191534 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
git checkout 6e9f7c08eb403975521108d1f10b77f8990cfe0c
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   net/ceph/debugfs.c: In function 'ceph_debugfs_init':
>> net/ceph/debugfs.c:459:9: warning: 'return' with a value, in function 
>> returning void
 return 0;
^
--
   fs/ceph/debugfs.c: In function 'ceph_fs_debugfs_init':
>> fs/ceph/debugfs.c:267:9: warning: 'return' with a value, in function 
>> returning void
 return 0;
^

vim +/return +459 net/ceph/debugfs.c

3d14c5d2 Yehuda Sadeh   2010-04-06  456  
6e9f7c08 Greg Kroah-Hartman 2019-01-04  457  void __init ceph_debugfs_init(void)
3d14c5d2 Yehuda Sadeh   2010-04-06  458  {
3d14c5d2 Yehuda Sadeh   2010-04-06 @459 return 0;
3d14c5d2 Yehuda Sadeh   2010-04-06  460  }
3d14c5d2 Yehuda Sadeh   2010-04-06  461  

:: The code at line 459 was first introduced by commit
:: 3d14c5d2b6e15c21d8e5467dc62d33127c23a644 ceph: factor out libceph from 
Ceph file system

:: TO: Yehuda Sadeh 
:: CC: Sage Weil 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] staging: iio: ad7192: Fix style issue

[Vladimir Petrigo]

On Mon, Mar 18, 2019 at 10:27:57AM +0800, Phil Reid wrote:
> On 18/03/2019 4:53 am, Vladimir Petrigo wrote:
> >Signed-off-by: Vladimir Petrigo 
> >---
> >  drivers/staging/iio/adc/ad7192.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/staging/iio/adc/ad7192.c 
> >b/drivers/staging/iio/adc/ad7192.c
> >index acdbc07..7c632cf 100644
> >--- a/drivers/staging/iio/adc/ad7192.c
> >+++ b/drivers/staging/iio/adc/ad7192.c
> >@@ -355,7 +355,7 @@ ad7192_show_scale_available(struct device *dev,
> >  }
> >  static IIO_DEVICE_ATTR_NAMED(in_v_m_v_scale_available,
> >- in_voltage-voltage_scale_available,
> >+ in_voltage - voltage_scale_available,
> >  0444, ad7192_show_scale_available, NULL, 0);
> >  static IIO_DEVICE_ATTR(in_voltage_scale_available, 0444,
> >
> G'day Vladimir ,
> 
> This is not a mathematical op.
> It gets passed to __ATTR() macro and converted to a string.
> 
> 
> -- 
> Regards
> Phil
Hello Phil,

Thank you for the prompt reply.
Should I remove that changes from the patchset v2 then?

--
Best regards,
Vladimir
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Shipping documents W2019004AI

[Nolan Transportation Group]

Hi ,

Attached please find the copy of the shipping documents from L-
Tech On Board 3/11/2019 for your reference.

If you have any questions, please do not hesitate to let us know.

Thank you. 


Regards,


Lighting SPOT26 LLC
Bright up your Life 

SHIPPING DOCUMENTS.xlsx
Description: Binary data
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel