Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Mon, Jan 22, 2007 at 12:03:21AM +0100, Willy Tarreau wrote:
 Hi Grant !
 
 On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
  On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:
  
  On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
  Ah, think I see the problem now:
  
  --- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 
  17:53:57.247695476 -0700
  +++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
  -0700
  @@ -1997,7 +1997,7 @@
 fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
   S_IRWXO)) | S_IFDIR;
 else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
   !(S_ISDIR(fattr-f_mode)) )
  -  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | S_IFREG;
  +  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | (fattr-f_mode  S_IFMT);
   
   }
   
  client running 2.4.34 with above patch, server is running 2.6.19.2 to 
  eliminate it from the problem space (hopefully ;) :
  [EMAIL PROTECTED]:/home/other$ uname -r
  2.4.34b
  [EMAIL PROTECTED]:/home/other$ ls -l
  total 9
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
 
 It seems to me that there is a difference, because filelink now appears the
 same size as file. It's just as if we had hard links instead of symlinks.

I was running into this yesterday - turns out that Debian's current
smbfs package contains a patch that checks for user passed options,
and disables unix capabilities in that case. It was added in
3.0.14a-4. I've filed a bug requesting the removal of this patch:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408033

Grant: Do you know if are you running a version of smbfs w/ this
   patch?

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

Users have reported a symlink issue with my recent smbfs backport.
Turns out my backport overlooked a second 2.6 patch w/ the fix:
 
http://linux.bkbits.net:8080/linux-2.6/?PAGE=csetREV=419e7b76CdrmRG_NZ8LKj9DUUBGu1w

This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
issue, and also cleans up an unnecessary double assignment. As his
commit message notes, you will need the userspace patches from Samba
Bug #999 in order to use the permission/ownership assigned by the
server.

Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
index be975fe..7fd9b51 100644
--- a/fs/smbfs/inode.c
+++ b/fs/smbfs/inode.c
@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
int silent)
mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
} else {
-   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFREG;
-   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFDIR;
+   mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFREG;
+   mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFDIR;
if (parse_options(mnt, raw_data))
goto out_bad_option;
}
diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
index 7f0794c..5570007 100644
--- a/fs/smbfs/proc.c
+++ b/fs/smbfs/proc.c
@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
struct smb_sb_info *server,
 
if ( (server-mnt-flags  SMB_MOUNT_DMODE) 
 (S_ISDIR(fattr-f_mode)) )
-   fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
+   fattr-f_mode = (server-mnt-dir_mode  S_IRWXUGO) | S_IFDIR;
else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
  !(S_ISDIR(fattr-f_mode)) )
-   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+   fattr-f_mode = (server-mnt-file_mode  S_IRWXUGO) |
+   (fattr-f_mode  S_IFMT);
 
 }
 


-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 24, 2007 at 08:04:36AM +1100, Grant Coady wrote:
 Hi Dann,
 I'm running slackware-11, no smbfs package, 'smbmnt' is from samba-3.0.23c 
 package with two tiny unrelated (?) patches:

Thanks again Grant. You might check out the patch I just submitted -
turns out this was an issue that was already fixed in 2.6, and that
fix is more complete than my previous one. You'll need the additional
userspace patches to use the server-provided perms (i.e., get rid of
the +x bits).

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 24, 2007 at 10:46:24AM +1100, Grant Coady wrote:
 On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier [EMAIL PROTECTED] wrote:
 
 Users have reported a symlink issue with my recent smbfs backport.
 Turns out my backport overlooked a second 2.6 patch w/ the fix:
  http://linux.bkbits.net:8080/linux-2.6/?PAGE=csetREV=419e7b76CdrmRG_NZ8LKj9DUUBGu1w
 
 This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
 issue, and also cleans up an unnecessary double assignment. As his
 commit message notes, you will need the userspace patches from Samba
 Bug #999 in order to use the permission/ownership assigned by the
 server.
 
 Server-side:
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.6.19.2a
 [EMAIL PROTECTED]:/home/other$ ls -l
 total 8
 drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
 lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink - dir/
 -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
 lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink - file
 -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
 lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink - test
 
 Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
 for comparison:
 
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.4.33.3
 [EMAIL PROTECTED]:/home/other$ ls -l
 total 4096
 drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
 lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink - dir/
 -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
 lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink - file
 -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
 lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink - test
 
 [EMAIL PROTECTED]:~$ uname -r
 2.6.19.2a
 [EMAIL PROTECTED]:~$ ls -l /home/other/
 total 10
 drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
 lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
 -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
 lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
 -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
 lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink - test*
 
 [EMAIL PROTECTED]:~$ uname -r
 2.4.34c
 [EMAIL PROTECTED]:~$ ls -l /home/other/
 total 4096
 drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
 lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
 -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
 lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
 -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
 lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink - test*

Great, that's what I'd expect. If you patch your userspace, you can
avoid the executable bits.


-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

udev/aacraid interaction - should aacraid set 'removable'?

[dann frazier]

(lkml readers: this concerns a security issue reported to debian by a
user of udev/aacraid. udev gives the aacraid devices the floppy group
because it reports block devices as 'removable'. See
http://bugs.debian.org/404927 for the entire thread).

On Wed, Jan 03, 2007 at 11:49:51AM +0100, Marco d'Itri wrote:
 On Jan 03, dann frazier [EMAIL PROTECTED] wrote:
 
   Can you elaborate on what you believe the kernel is doing
  incorrectly? My first guess would be the setting of the removable
  flag, but aacraid claims to be setting this to prevent partition table
  caching - do you believe that to be an incorrect usage?
 Yes, this looks like an abuse of the interface to me.

Ok, let's ask lkml

  It seems like there is precedence for workarounds for older kernels in
  permissions.rules, so would it be appropriate to add an override of
  the default floppy rule for aacraid devices for compatability even if
  this is a kernel bug?
 There are workarounds for bugs which are going to be fixed, but looks
 like this is going to stay forever...
 Are there other drivers in this situation?

I didn't turn up any otherwise when I was grepping yesterday, but my
search terms may have been too naive. I also checked a machine I had
w/ cciss - it did not have the removable flag set.

I found a message from Mark Salyzyn from last year that suggested this
was more pervasive:
  http://www.ussg.iu.edu/hypermail/linux/kernel/0602.2/1231.html
Mark: Can you identify some of these other drivers?


-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: udev/aacraid interaction - should aacraid set 'removable'?

[dann frazier]

On Wed, Jan 03, 2007 at 12:17:47PM -0500, Salyzyn, Mark wrote:
 The ips driver, indirectly via Firmware as it spoofs it's own inquiry
 data, reports the Removable bit set in the inquiry response for the
 arrays. The dpt_i2o driver similarly has the firmware constructing the
 bit set. Some of the Array Bridges and external RAID boxes do the same
 thing.

Thanks Mark. If you have any of these devices, could you help supply
the udevinfo information? Our udev maintainer has asked for this so
that he can workaround this issue by special casing these
devices. (See http://bugs.debian.org/404927 for details).

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
 Dann, do you still have your samba server ready to try to reproduce this
 problem ? Also, there are very suspect lines right there in the patch :

I can set it up again, hopefully have some feedback by tomorrow.

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
 @@ -505,8 +510,13 @@
   mnt-file_mode = (oldmnt-file_mode  S_IRWXUGO) | S_IFREG;
   mnt-dir_mode = (oldmnt-dir_mode  S_IRWXUGO) | S_IFDIR;
  
 - mnt-flags = (oldmnt-file_mode  9);
 + mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
 + SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
   } else {
 + mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 + S_IROTH | S_IXOTH | S_IFREG;
 + mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 + S_IROTH | S_IXOTH | S_IFDIR;
   if (parse_options(mnt, raw_data))
   goto out_bad_option;
   }
 
 
 See above ? mnt-dir_mode being assigned 3 times. It still *seems* to do the
 expected thing like this but I wonder if the initial intent was
 exactly this.

Wow - sorry about that, that's certainly a cut  paste error. But the
end result appears to match current 2.6, which was the intent.

 Also, would not it be necessary to add |S_IFLNK to the file_mode ? Maybe
 what I say is stupid, but it's just a guess.

I really don't know the correct answer to that, I was merely copying
the 2.6 flags. 

[Still working on getting a 2.4 smbfs test system up...]

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/12] repost: cciss: add busy_configuring flag

[dann frazier]

On Wed, Dec 13, 2006 at 01:52:36PM +0100, Jens Axboe wrote:
 On Tue, Dec 12 2006, Mike Miller (OS Dev) wrote:
  On Mon, Nov 06, 2006 at 09:32:00PM +0100, Jens Axboe wrote:
   On Mon, Nov 06 2006, Mike Miller (OS Dev) wrote:
PATCH 9 of 12

This patch adds a check for busy_configuring to prevent starting a queue
on a drive that may be in the midst of updating, configuring, deleting, 
etc.

This had a test for if the queue was stopped or plugged but that seemed
to cause issues.
Please consider this for inclusion.

Thanks,
mikem

Signed-off-by: Mike Miller [EMAIL PROTECTED]



---

 drivers/block/cciss.c |5 -
 1 files changed, 4 insertions(+), 1 deletion(-)

diff -puN drivers/block/cciss.c~cciss_busy_conf_for_lx2619-rc4 
drivers/block/cciss.c
--- linux-2.6/drivers/block/cciss.c~cciss_busy_conf_for_lx2619-rc4  
2006-11-06 13:27:53.0 -0600
+++ linux-2.6-root/drivers/block/cciss.c2006-11-06 
13:27:53.0 -0600
@@ -1190,8 +1190,11 @@ static void cciss_check_queues(ctlr_info
/* make sure the disk has been added and the drive is 
real
 * because this can be called from the middle of 
init_one.
 */
-   if (!(h-drv[curr_queue].queue) || 
!(h-drv[curr_queue].heads))
+   if (!(h-drv[curr_queue].queue) ||
+   !(h-drv[curr_queue].heads) ||
+   h-drv[curr_queue].busy_configuring)
continue;
+
blk_start_queue(h-gendisk[curr_queue]-queue);
   
   This is racy, because you don't start the queue when you unset
   -busy_configuring later on. For this to be safe, you need to call
   blk_start_queue() when you set -busy_configuring to 0.
  
  Jens, please see Chase's reply to your concerns:
   busy_configuring - I do not think this is racy.  This
   flag is used only when we are removing/deleting a disk.  In
   this case the queue is cleaned up and the disk is deleted.
   If we are doing that then there is no queue to start later.
   The check of this flag in the interrupt handler is to prevent
   us from trying to start a queue that is in the middle of
   being deleted.  This flag could be called busy_deleting.
 
 Ok, no worries then if it's simply a going away flag. I wonder if it's
 needed at all, but it certainly doesn't hurt.

hey Jens,
  Just a poke since I haven't seen this change go into your block
tree. Is it still in-plan?

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
 On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
  @@ -505,8 +510,13 @@
  mnt-file_mode = (oldmnt-file_mode  S_IRWXUGO) | S_IFREG;
  mnt-dir_mode = (oldmnt-dir_mode  S_IRWXUGO) | S_IFDIR;
   
  -   mnt-flags = (oldmnt-file_mode  9);
  +   mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
  +   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
  } else {
  +   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
  +   S_IROTH | S_IXOTH | S_IFREG;
  +   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
  +   S_IROTH | S_IXOTH | S_IFDIR;
  if (parse_options(mnt, raw_data))
  goto out_bad_option;
  }
  
  
  See above ? mnt-dir_mode being assigned 3 times. It still *seems* to do the
  expected thing like this but I wonder if the initial intent was
  exactly this.
 
 Wow - sorry about that, that's certainly a cut  paste error. But the
 end result appears to match current 2.6, which was the intent.
 
  Also, would not it be necessary to add |S_IFLNK to the file_mode ? Maybe
  what I say is stupid, but it's just a guess.
 
 I really don't know the correct answer to that, I was merely copying
 the 2.6 flags. 
 
 [Still working on getting a 2.4 smbfs test system up...]

Ah, think I see the problem now:

--- kernel-source-2.4.27.orig/fs/smbfs/proc.c   2007-01-19 17:53:57.247695476 
-0700
+++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 
-0700
@@ -1997,7 +1997,7 @@
fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
  !(S_ISDIR(fattr-f_mode)) )
-   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | (fattr-f_mode  S_IFMT);
 
 }
 
Santiago: Thanks for reporting this - can you test this patch out on
your system and let me know if there are still any problems?

Willy: I'll do some more testing and get you a patch that fixes this
and the double assignment nonsense. Would you prefer a single patch or
two?

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Mon, Jan 22, 2007 at 10:50:47AM +1100, Grant Coady wrote:
 On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.4.34b
 [EMAIL PROTECTED]:/home/other$ mkdir test
 [EMAIL PROTECTED]:/home/other$ ln -s test testlink
 ln: creating symbolic link `testlink' to `test': Operation not permitted
 [EMAIL PROTECTED]:/home/other$ echo this is also a test  test/file
 [EMAIL PROTECTED]:/home/other$ ln -s test/file test2
 ln: creating symbolic link `test2' to `test/file': Operation not permitted
 
 trying to create symlinks.
 
 No problems creating symlinks with 2.4.33.3.

Yes, I've found that this varies depending upon the options passed. If
uid=0, I can create symlinks, otherwise I always get permission
denied. This behavior appears to be consistent with 2.6.

I also need to do some testing with the proposed patch to smbmount
that will let you omit options (current versions will always pass an
option to the kernel, even if you the user did not provide one).
If you do not pass options, the behavior should fallback to
server-provided values.

Note that this bug has been my only interaction with smbfs, so I'm
certainly no expert on how it *should* behave. My plan is to
take all of the use cases we're coming up with and try to maintain
the historic 2.4 behavior as much as possible, but still not
silently dropping user-provided mount options. When the behavior needs
to change to honor them, I'll try to match what current 2.6
does. Make sense?

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19-git20 cciss: cmd f7b00000 timedout

[dann frazier]

On Thu, Dec 14, 2006 at 01:44:34PM -0600, Miller, Mike (OS Dev) wrote:
  
 
  -Original Message-
  From: Jens Axboe [mailto:[EMAIL PROTECTED] 
  Sent: Thursday, December 14, 2006 12:51 PM
  To: Steve Roemen
  Cc: LKML; ISS StorageDev; Miller, Mike (OS Dev)
  Subject: Re: 2.6.19-git20 cciss: cmd f7b0 timedout
  
  On Thu, Dec 14 2006, Steve Roemen wrote:
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1
   
   All,
   I tried out the 2.6.19-git20 kernel on one of my machines (HP 
   DL380 G3) that has the on board 5i controller (disabled),
   2 smart array 642 controllers.
   
   I get the error (cciss: cmd f7b0 timedout) with Buffer 
  I/O error 
   on device cciss/c (all cards, and disks) logical block 0, 1, 2, etc
  
  I saw this on another box, but it works on the ones that I have. Does
  2.6.19 work? Any chance you can try and narrow down when it broke?
 
 Jens/Steve:
 We also encountered a time out issue on the 642. This one is connected
 to an MSA500. Do either of you have MSA500? What controller fw are you
 running? Check /proc/driver/cciss/ccissN.

fyi, we've been seeing this in Debian too (which is why Mike added me
to the CC list), and I've narrowed it down to the 2TB patch that went
into 2.6.19:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402787
-- 
dann frazier | HP Open Source and Linux Organization
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19-git20 cciss: cmd f7b00000 timedout

[dann frazier]

On Thu, Dec 14, 2006 at 04:16:39PM -0600, Miller, Mike (OS Dev) wrote:
 H. Dann, did you see this on 32-bit Debian?

yep - all reports I've seen so far are on i386



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [SCSI] aacraid: Fix security hole

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Alan Cox.
(commit 60395bb60e0b5e4e0808ac8eb07a92f6c9cdea1f)

It has been build-tested only (I don't have the hardware).
CVE-2007-4308 was assigned for this issue.

Commit log from 2.6 follows.

  On the SCSI layer ioctl path there is no implicit permissions check for
  ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
  however allows all sorts of very admin only things to be done so should
  check.
---
 drivers/scsi/aacraid/linit.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 57d0a40..c6d7bdf 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -683,6 +683,8 @@ static int aac_cfg_release(struct inode * inode, struct 
file * file )
 static int aac_cfg_ioctl(struct inode * inode,  struct file * file, unsigned 
int cmd, unsigned long arg )
 {
struct aac_dev *dev = aac_devices[MINOR(inode-i_rdev)];
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
return aac_do_ioctl(dev, cmd, (void *)arg);
 }
 
-- 
1.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [PPPOE]: memory leak when socket is release()d before PPPIOCGCHAN has been called on it

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Florian Zumbiehl.
(commit 202a03acf9994076055df40ae093a5c5474ad0bd)

CVE-2007-2525 was assigned for this issue. It has been compile tested-only.

Commit log from 2.6 follows.

  below you find a patch that fixes a memory leak when a PPPoE socket is
  release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl
  ever has been called on it.

  This is somewhat of a security problem, too, since PPPoE sockets can be
  created by any user, so any user can easily allocate all the machine's
  RAM to non-swappable address space and thus DoS the system.

  Is there any specific reason for PPPoE sockets being available to any
  unprivileged process, BTW? After all, you need a packet socket for the
  discovery stage anyway, so it's unlikely that any unprivileged process
  will ever need to create a PPPoE socket, no? Allocating all session IDs
  for a known AC is a kind of DoS, too, after all - with Juniper ERXes,
  this is really easy, actually, since they don't ever assign session ids
  above 8000 ...

Signed-off-by: dann frazier [EMAIL PROTECTED]
---
 drivers/net/pppox.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/pppox.c b/drivers/net/pppox.c
index 7830e4d..4883c0f 100644
--- a/drivers/net/pppox.c
+++ b/drivers/net/pppox.c
@@ -67,7 +67,7 @@ void pppox_unbind_sock(struct sock *sk)
 {
/* Clear connection to ppp device, if attached. */
 
-   if (sk-state  (PPPOX_BOUND|PPPOX_ZOMBIE)) {
+   if (sk-state  (PPPOX_BOUND | PPPOX_CONNECTED | PPPOX_ZOMBIE)) {
ppp_unregister_channel(sk-protinfo.pppox-chan);
sk-state = PPPOX_DEAD;
}
-- 
1.5.3.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: USB: fix DoS in pwc USB video driver

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Oliver Neukum.
(commit 85237f202d46d55c1bffe0c5b1aa3ddc0f1dce4d)

CVE-2007-5093 was assigned for this issue.
This backport has been compile-tested only.

Commit log from 2.6 follows.

  the pwc driver has a disconnect method that waits for user space to
  close the device. This opens up an opportunity for a DoS attack,
  blocking the USB subsystem and making khubd's task busy wait in
  kernel space. This patch shifts freeing resources to close if an opened
  device is disconnected.

Signed-off-by: dann frazier [EMAIL PROTECTED]
---
 drivers/usb/pwc-if.c |   50 +-
 drivers/usb/pwc.h|1 +
 2 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/pwc-if.c b/drivers/usb/pwc-if.c
index e458515..a1c3989 100644
--- a/drivers/usb/pwc-if.c
+++ b/drivers/usb/pwc-if.c
@@ -1055,11 +1055,16 @@ static int pwc_video_open(struct video_device *vdev, 
int mode)
return 0;
 }
 
+static void pwc_cleanup(struct pwc_device *pdev)
+{
+   video_unregister_device(pdev-vdev);
+}
+
 /* Note that all cleanup is done in the reverse order as in _open */
 static void pwc_video_close(struct video_device *vdev)
 {
struct pwc_device *pdev;
-   int i;
+   int i, hint;
 
Trace(TRACE_OPEN,  video_close called(vdev = 0x%p).\n, vdev);
 
@@ -1083,8 +1088,9 @@ static void pwc_video_close(struct video_device *vdev)
pwc_isoc_cleanup(pdev);
pwc_free_buffers(pdev);
 
+   lock_kernel();
/* Turn off LEDS and power down camera, but only when not unplugged */
-   if (pdev-error_status != EPIPE) {
+   if (!pdev-unplugged) {
if (pwc_set_leds(pdev, 0, 0)  0)
Info(Failed to set LED on/off time.\n);
if (power_save) {
@@ -1092,9 +1098,18 @@ static void pwc_video_close(struct video_device *vdev)
if (i  0) 
Err(Failed to power down camera (%d)\n, i);
}
+   pdev-vopen = 0;
+   Trace(TRACE_OPEN,  video_close()\n);
+   } else {
+   pwc_cleanup(pdev);
+   /* Free memory (don't set pdev to 0 just yet) */
+   kfree(pdev);
+   /* search device_hint[] table if we occupy a slot, by any 
chance */
+   for (hint = 0; hint  MAX_DEV_HINTS; hint++)
+   if (device_hint[hint].pdev == pdev)
+   device_hint[hint].pdev = NULL;
}
-   pdev-vopen = 0;
-   Trace(TRACE_OPEN,  video_close()\n);
+   unlock_kernel();
 }
 
 /*
@@ -1897,19 +1912,20 @@ static void usb_pwc_disconnect(struct usb_device *udev, 
void *ptr)
/* Alert waiting processes */
wake_up_interruptible(pdev-frameq);
/* Wait until device is closed */
-   while (pdev-vopen)
-   schedule();
-   /* Device is now closed, so we can safely unregister it */
-   Trace(TRACE_PROBE, Unregistering video device in disconnect().\n);
-   video_unregister_device(pdev-vdev); 
-
-   /* Free memory (don't set pdev to 0 just yet) */
-   kfree(pdev);
-
-   /* search device_hint[] table if we occupy a slot, by any chance */
-   for (hint = 0; hint  MAX_DEV_HINTS; hint++)
-   if (device_hint[hint].pdev == pdev)
-   device_hint[hint].pdev = NULL;
+   if(pdev-vopen) {
+   pdev-unplugged = 1;
+   } else {
+   /* Device is closed, so we can safely unregister it */
+   Trace(TRACE_PROBE, Unregistering video device in 
disconnect().\n);
+   pwc_cleanup(pdev);
+   /* Free memory (don't set pdev to 0 just yet) */
+   kfree(pdev);
+   
+   /* search device_hint[] table if we occupy a slot, by any 
chance */
+   for (hint = 0; hint  MAX_DEV_HINTS; hint++)
+   if (device_hint[hint].pdev == pdev)
+   device_hint[hint].pdev = NULL;
+   }
 
unlock_kernel();
 }
diff --git a/drivers/usb/pwc.h b/drivers/usb/pwc.h
index b020769..999daf2 100644
--- a/drivers/usb/pwc.h
+++ b/drivers/usb/pwc.h
@@ -141,6 +141,7 @@ struct pwc_device
char vsnapshot; /* snapshot mode */
char vsync; /* used by isoc handler */
char vmirror;   /* for ToUCaM series */
+   char unplugged;
 
/* The image acquisition requires 3 to 4 steps:
   1. data is gathered in short packets from the USB controller
-- 
1.5.3.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
(commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)

CVE-2006-5753 was assigned for this issue.

I've built and boot-tested this, but I'm not sure how to exercise
these codepaths.

Commit log from 2.6 follows.

  CVE-2006-5753 is for a case where an inode can be marked bad, switching
  the ops to bad_inode_ops, which are all connected as:

  static int return_EIO(void)
  {
  return -EIO;
  }

  #define EIO_ERROR ((void *) (return_EIO))

  static struct inode_operations bad_inode_ops =
  {
  .create = bad_inode_create
  ...etc...

  The problem here is that the void cast causes return types to not be
  promoted, and for ops such as listxattr which expect more than 32 bits of
  return value, the 32-bit -EIO is interpreted as a large positive 64-bit
  number, i.e. 0xfffa instead of 0xfffa.

  This goes particularly badly when the return value is taken as a number of
  bytes to copy into, say, a user's buffer for example...

  I originally had coded up the fix by creating a return_EIO_TYPE macro
  for each return type, like this:

  static int return_EIO_int(void)
  {
return -EIO;
  }
  #define EIO_ERROR_INT ((void *) (return_EIO_int))

  static struct inode_operations bad_inode_ops =
  {
.create = EIO_ERROR_INT,
  ...etc...

  but Al felt that it was probably better to create an EIO-returner for each
  actual op signature.  Since so few ops share a signature, I just went ahead
   created an EIO function for each individual file  inode op that returns
  a value.

Signed-off-by: dann frazier [EMAIL PROTECTED]
---
 fs/bad_inode.c |  191 +++-
 1 files changed, 161 insertions(+), 30 deletions(-)

diff --git a/fs/bad_inode.c b/fs/bad_inode.c
index 850ba5e..b6b1d7d 100644
--- a/fs/bad_inode.c
+++ b/fs/bad_inode.c
@@ -9,6 +9,76 @@
 #include linux/fs.h
 #include linux/stat.h
 #include linux/sched.h
+#include linux/poll.h
+
+static loff_t bad_file_llseek(struct file *file, loff_t offset, int origin)
+{
+   return -EIO;
+}
+
+static ssize_t bad_file_read(struct file *filp, char __user *buf,
+   size_t size, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_write(struct file *filp, const char __user *buf,
+   size_t siz, loff_t *ppos)
+{
+return -EIO;
+}
+
+static int bad_file_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+   return -EIO;
+}
+
+static unsigned int bad_file_poll(struct file *filp, poll_table *wait)
+{
+   return POLLERR;
+}
+
+static int bad_file_ioctl (struct inode *inode, struct file *filp,
+   unsigned int cmd, unsigned long arg)
+{
+   return -EIO;
+}
+
+static int bad_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   return -EIO;
+}
+
+static int bad_file_open(struct inode *inode, struct file *filp)
+{
+   return -EIO;
+}
+
+static int bad_file_flush(struct file *file)
+{
+   return -EIO;
+}
+
+static int bad_file_release(struct inode *inode, struct file *filp)
+{
+   return -EIO;
+}
+
+static int bad_file_fsync(struct file *file, struct dentry *dentry,
+   int datasync)
+{
+   return -EIO;
+}
+
+static int bad_file_fasync(int fd, struct file *filp, int on)
+{
+   return -EIO;
+}
+
+static int bad_file_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+   return -EIO;
+}
 
 /*
  * The follow_link operation is special: it must behave as a no-op
@@ -20,46 +90,107 @@ static int bad_follow_link(struct dentry *dent, struct 
nameidata *nd)
return vfs_follow_link(nd, ERR_PTR(-EIO));
 }
 
-static int return_EIO(void)
+static struct file_operations bad_file_ops =
+{
+   llseek: bad_file_llseek,
+   read:   bad_file_read,
+   write:  bad_file_write,
+   readdir:bad_file_readdir,
+   poll:   bad_file_poll,
+   ioctl:  bad_file_ioctl,
+   mmap:   bad_file_mmap,
+   open:   bad_file_open,
+   flush:  bad_file_flush,
+   release:bad_file_release,
+   fsync:  bad_file_fsync,
+   fasync: bad_file_fasync,
+   lock:   bad_file_lock,
+};
+
+static int bad_inode_create (struct inode *dir, struct dentry *dentry,
+   int mode)
 {
return -EIO;
 }
+  
+static struct dentry *bad_inode_lookup(struct inode *dir,
+   struct dentry *dentry)
+{
+   return ERR_PTR(-EIO);
+}
 
-#define EIO_ERROR ((void *) (return_EIO))
+static int bad_inode_link (struct dentry *old_dentry, struct inode *dir,
+   struct dentry *dentry)
+{
+   return -EIO;
+}
 
-static struct file_operations bad_file_ops =
+static int bad_inode_unlink(struct inode *dir, struct dentry *dentry)
 {
-   llseek: EIO_ERROR,
-   read:   EIO_ERROR,
-   write

Re: [PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

[dann frazier]

On Thu, Jan 24, 2008 at 03:06:58PM -0600, Eric Sandeen wrote:
 Willy Tarreau wrote:
  Hi Dann,
  
  On Wed, Jan 23, 2008 at 11:12:12PM -0700, dann frazier wrote:
  This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
  (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)
 
  CVE-2006-5753 was assigned for this issue.
 
  I've built and boot-tested this, but I'm not sure how to exercise
  these codepaths.
  
  I have no idea either. Let's consider that if nobody on the list knows
  how to do so, I'll merge it since you did not notice any regression.
  
  Thanks,
  Willy
  
 
 Sorry... here you go.  Forgot to post this sooner.  I hit it with
 this on 2.6.x
 
 #include stdio.h
 #include sys/types.h
 #include sys/errno.h
 
 static int return_EIO(void)
 {
 return -EIO;
 }
 
 int main(int argc, char ** argv)
 {
   ssize_t error;
   ssize_t realerror = -EIO;
   ssize_t (*fn_ptr)(void);
 
   fn_ptr = (void *)return_EIO;
 
   error = (ssize_t)fn_ptr();
   printf(and... error is %ld, should be %ld\n, error, realerror);
   return 0;
 }

Thanks Eric. Sounds like my comment about exercising these code paths
wasn't too clear - the comments with your patch do make the issue
clear, and this program demonstrates the void cast promotion issue
well. I'm just not sure of a good way to demonstrate that my backport
of this patch doesn't break anything for 2.4.

-- 
dann frazier

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [POWERPC] CHRP: Fix possible NULL pointer dereference

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Cyrill Gorcunov.
(commit 9ac71d00398674aaec664f30559f0a21d963862f)

CVE-2007-6694 was assigned for this issue.
This backport has been compile-tested only.

Commit log from 2.6 follows.

This fixes a possible NULL pointer dereference inside of strncmp() if
of_get_property() fails.

Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c
index 0ffbbd2..28747db 100644
--- a/arch/ppc/platforms/chrp_setup.c
+++ b/arch/ppc/platforms/chrp_setup.c
@@ -121,7 +121,7 @@ chrp_show_cpuinfo(struct seq_file *m)
seq_printf(m, machine\t\t: CHRP %s\n, model);
 
/* longtrail (goldengate) stuff */
-   if (!strncmp(model, IBM,LongTrail, 13)) {
+   if (model  !strncmp(model, IBM,LongTrail, 13)) {
/* VLSI VAS96011/12 `Golden Gate 2' */
/* Memory banks */
sdramen = (in_le32((unsigned *)(gg2_pci_config_base+
@@ -210,14 +210,20 @@ static void __init sio_fixup_irq(const char *name, u8 
device, u8 level,
 static void __init sio_init(void)
 {
struct device_node *root;
+   const char *model;
 
-   if ((root = find_path_device(/)) 
-   !strncmp(get_property(root, model, NULL), IBM,LongTrail, 13)) {
+   root = find_path_device(/);
+   if (!root)
+   return;
+
+   model = get_property(root, model, NULL);
+   if (model  !strncmp(model, IBM,LongTrail, 13)) {
/* logical device 0 (KBC/Keyboard) */
sio_fixup_irq(keyboard, 0, 1, 2);
/* select logical device 1 (KBC/Mouse) */
sio_fixup_irq(mouse, 1, 12, 2);
}
+
 }
 
 
-- 
1.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.4.36.1 hangs.

[dann frazier]

On Tue, Feb 26, 2008 at 09:16:25AM +0100, Willy Tarreau wrote:
 On Mon, Feb 25, 2008 at 09:36:12PM -1000, Glen Nakamura wrote:
  Aloha,
  
  The ext2_readdir() filp-f_pos fix patch looks weird...
  Perhaps the filp-f_pos += le16_to_cpu(de-rec_len); line should be
  outside of the if statement like the indentation implies?
 
 good catch! At least it's what is done in 2.6.

Yes, that certainly looks like a bug.

  As it is, filp-f_pos gets corrupted if de-inode is ever zero...
  This could possibly explain why I had a few strange directory
  entries until I checked the filesystem with:
  e2fsck -D -F -f /dev/{ext2 partition}
  
  - glen
  
  Here is an updated (untested) patch:
 
 unfortunately, neither Dann nor me could reproduce the issue, so
 we'll wait for some victims^Wvolunteers to give it a try.

I'm now able to reliably reproduce it by creating/removing a chroot
(pbuilder create on a Debian system, though I'm sure a simpler test
exists). Correcting the le16_to_cpu placement as Glen described
fixes the issue for me.

 BTW, I notice that 2.6 also has one extra chunk that 2.4 does not
 have :
 
 if (unlikely(need_revalidate)) {
 +   if (offset) {
 offset = ext2_validate_entry(kaddr, offset, 
 chunk_mask);
 +   filp-f_pos = (nPAGE_CACHE_SHIFT) + offset;
 +   }
 +   filp-f_version = inode-i_version;
 need_revalidate = 0;
 }
 
 I have no idea whether this part is needed, we'd better ask Theo or Al
 for some advices, as I'm not tempted by merging an uncertain patch when
 it comes to filesystems.

Looks like a test case may be available:
  
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2d7f2ea9c989853310c7f6e8be52cc090cc8e66b

-- 
dann frazier

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

old buffer overflow in moxa driver

[dann frazier]

hey,
  I noticed that the moxa input checking security bug described by
CVE-2005-0504 appears to remain unfixed upstream.
 
The issue is described here:
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504

Debian has been shipping the following patch from Andres Salomon. I
tried contacting the listed maintainer a few months ago but received
no response.

I've tested that this still applies to and compiles against 2.6.21.

Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index 7dbaee8..e0d35c2 100644
--- a/drivers/char/moxa.c
+++ b/drivers/char/moxa.c
@@ -1582,7 +1582,7 @@ copy:
 
if(copy_from_user(dltmp, argp, sizeof(struct dl_str)))
return -EFAULT;
-   if(dltmp.cardno  0 || dltmp.cardno = MAX_BOARDS)
+   if(dltmp.cardno  0 || dltmp.cardno = MAX_BOARDS || dltmp.len  0)
return -EINVAL;
 
switch(cmd)
@@ -2529,6 +2529,8 @@ static int moxaloadbios(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr;
int i;
 
+   if(len  0 || len  sizeof(moxaBuff))
+   return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
baseAddr = moxa_boards[cardno].basemem;
@@ -2576,7 +2578,7 @@ static int moxaload320b(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr;
int i;
 
-   if(len  sizeof(moxaBuff))
+   if(len  0 || len  sizeof(moxaBuff))
return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
@@ -2596,6 +2598,8 @@ static int moxaloadcode(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr, *ofsAddr;
int retval, port, i;
 
+   if(len  0 || len  sizeof(moxaBuff))
+   return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
baseAddr = moxa_boards[cardno].basemem;

-- 
dann frazier
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: old buffer overflow in moxa driver

[dann frazier]

On Tue, May 01, 2007 at 04:29:27AM -0400, Andres Salomon wrote:
 Right; the lack of input checking is most definitely a bug.  It's no
 longer a security issue, as a CAP_SYS_RAWIO check was added at some
 point to the code path, but it's still a bug.

I hadn't noticed this, but yes - the CAP_SYS_RAWIO check was added in
2.6.16.

-- 
dann frazier | HP Open Source and Linux Organization
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] serial: uart: add hw flow control support configuration

[Dann Frazier]

On Wed, Jun 11, 2014 at 2:53 PM, Murali Karicheri m-kariche...@ti.com wrote:
 On 5/28/2014 4:04 PM, Dann Frazier wrote:

 On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri m-kariche...@ti.com
 wrote:

 8250 uart driver currently supports only software assisted hw flow
 control. The software assisted hw flow control maintains a hw_stopped
 flag in the tty structure to stop and start transmission and use modem
 status interrupt for the event to drive the handshake signals. This is
 not needed if hw has flow control capabilities. This patch adds a
 DT attribute for enabling hw flow control for a uart port. Also skip
 stop and start if this flag is present in flag field of the port
 structure.

 ubuntu@hwflow:~$ sudo stty -a --file /dev/ttyS0 |tr ' ' '\n' | grep
 crtscts
 crtscts
 ubuntu@hwflow:~$ ls
 /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
 /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
 ubuntu@hwflow:~$ python
 Python 2.7.6 (default, Mar 22 2014, 22:58:30)
 [GCC 4.8.2] on linux2
 Type help, copyright, credits or license for more information.

 UPF_HARDWARE_FLOW = 1  21
 if 0xB920  UPF_HARDWARE_FLOW:

 ... print OK
 ...
 OK

 Hope that's a reasonable test case. Test fails when booted w/o
 has-hw-flow-control attribute.

 Tested-by: dann frazier dann.fraz...@canonical.com

 What is the verdict? pass/fail? Ok/Not OK to merge?

Murali,

 It is working for me, and appears to already be Linus' tree.

  -dann

 Murali

 Signed-off-by: Murali Karicheri m-kariche...@ti.com

 CC: Rob Herring robh...@kernel.org
 CC: Pawel Moll pawel.m...@arm.com
 CC: Mark Rutland mark.rutl...@arm.com
 CC: Ian Campbell ijc+devicet...@hellion.org.uk
 CC: Kumar Gala ga...@codeaurora.org
 CC: Randy Dunlap rdun...@infradead.org
 CC: Greg Kroah-Hartman gre...@linuxfoundation.org
 CC: Jiri Slaby jsl...@suse.cz
 CC: Santosh Shilimkar santosh.shilim...@ti.com
 ---
   .../devicetree/bindings/serial/of-serial.txt   |1 +
   drivers/tty/serial/8250/8250_core.c|6 --
   drivers/tty/serial/of_serial.c |4 
   drivers/tty/serial/serial_core.c   |   12 +---
   4 files changed, 18 insertions(+), 5 deletions(-)

 diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
 b/Documentation/devicetree/bindings/serial/of-serial.txt
 index 1928a3e..7705477 100644
 --- a/Documentation/devicetree/bindings/serial/of-serial.txt
 +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
 @@ -37,6 +37,7 @@ Optional properties:
   - auto-flow-control: one way to enable automatic flow control support.
 The
 driver is allowed to detect support for the capability even without
 this
 property.
 +- has-hw-flow-control: the hardware has flow control capability.

   Example:

 diff --git a/drivers/tty/serial/8250/8250_core.c
 b/drivers/tty/serial/8250/8250_core.c
 index 0e1bf88..b69aff2 100644
 --- a/drivers/tty/serial/8250/8250_core.c
 +++ b/drivers/tty/serial/8250/8250_core.c
 @@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port,
 struct ktermios *termios,
   * the trigger, or the MCR RTS bit is cleared.  In the case
 where
   * the remote UART is not using CTS auto flow control, we must
   * have sufficient FIFO entries for the latency of the remote
 -* UART to respond.  IOW, at least 32 bytes of FIFO.
 +* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
 +* AFE if hw flow control is supported
   */
 -   if (up-capabilities  UART_CAP_AFE  port-fifosize = 32) {
 +   if ((up-capabilities  UART_CAP_AFE  (port-fifosize = 32))
 ||
 +   (port-flags  UPF_HARD_FLOW)) {
  up-mcr = ~UART_MCR_AFE;
  if (termios-c_cflag  CRTSCTS)
  up-mcr |= UART_MCR_AFE;
 diff --git a/drivers/tty/serial/of_serial.c
 b/drivers/tty/serial/of_serial.c
 index 9924660..77ec6a1 100644
 --- a/drivers/tty/serial/of_serial.c
 +++ b/drivers/tty/serial/of_serial.c
 @@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct
 platform_device *ofdev)
auto-flow-control))
  port8250.capabilities |= UART_CAP_AFE;

 +   if (of_property_read_bool(ofdev-dev.of_node,
 + has-hw-flow-control))
 +   port8250.port.flags |= UPF_HARD_FLOW;
 +
  ret = serial8250_register_8250_port(port8250);
  break;
  }
 diff --git a/drivers/tty/serial/serial_core.c
 b/drivers/tty/serial/serial_core.c
 index b68550d..851707a 100644
 --- a/drivers/tty/serial/serial_core.c
 +++ b/drivers/tty/serial/serial_core.c
 @@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty,
 struct uart_state *state,
  if (tty-termios.c_cflag  CBAUD)
  uart_set_mctrl(uport, TIOCM_RTS |
 TIOCM_DTR

Re: [PATCH v2] serial: uart: add hw flow control support configuration

[Dann Frazier]

On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri m-kariche...@ti.com wrote:
 8250 uart driver currently supports only software assisted hw flow
 control. The software assisted hw flow control maintains a hw_stopped
 flag in the tty structure to stop and start transmission and use modem
 status interrupt for the event to drive the handshake signals. This is
 not needed if hw has flow control capabilities. This patch adds a
 DT attribute for enabling hw flow control for a uart port. Also skip
 stop and start if this flag is present in flag field of the port
 structure.

ubuntu@hwflow:~$ sudo stty -a --file /dev/ttyS0 |tr ' ' '\n' | grep crtscts
crtscts
ubuntu@hwflow:~$ ls /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
/proc/device-tree/soc/serial@1c021000/has-hw-flow-control
ubuntu@hwflow:~$ python
Python 2.7.6 (default, Mar 22 2014, 22:58:30)
[GCC 4.8.2] on linux2
Type help, copyright, credits or license for more information.
 UPF_HARDWARE_FLOW = 1  21
 if 0xB920  UPF_HARDWARE_FLOW:
... print OK
...
OK

Hope that's a reasonable test case. Test fails when booted w/o
has-hw-flow-control attribute.

Tested-by: dann frazier dann.fraz...@canonical.com


 Signed-off-by: Murali Karicheri m-kariche...@ti.com

 CC: Rob Herring robh...@kernel.org
 CC: Pawel Moll pawel.m...@arm.com
 CC: Mark Rutland mark.rutl...@arm.com
 CC: Ian Campbell ijc+devicet...@hellion.org.uk
 CC: Kumar Gala ga...@codeaurora.org
 CC: Randy Dunlap rdun...@infradead.org
 CC: Greg Kroah-Hartman gre...@linuxfoundation.org
 CC: Jiri Slaby jsl...@suse.cz
 CC: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  .../devicetree/bindings/serial/of-serial.txt   |1 +
  drivers/tty/serial/8250/8250_core.c|6 --
  drivers/tty/serial/of_serial.c |4 
  drivers/tty/serial/serial_core.c   |   12 +---
  4 files changed, 18 insertions(+), 5 deletions(-)

 diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt 
 b/Documentation/devicetree/bindings/serial/of-serial.txt
 index 1928a3e..7705477 100644
 --- a/Documentation/devicetree/bindings/serial/of-serial.txt
 +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
 @@ -37,6 +37,7 @@ Optional properties:
  - auto-flow-control: one way to enable automatic flow control support. The
driver is allowed to detect support for the capability even without this
property.
 +- has-hw-flow-control: the hardware has flow control capability.

  Example:

 diff --git a/drivers/tty/serial/8250/8250_core.c 
 b/drivers/tty/serial/8250/8250_core.c
 index 0e1bf88..b69aff2 100644
 --- a/drivers/tty/serial/8250/8250_core.c
 +++ b/drivers/tty/serial/8250/8250_core.c
 @@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, 
 struct ktermios *termios,
  * the trigger, or the MCR RTS bit is cleared.  In the case where
  * the remote UART is not using CTS auto flow control, we must
  * have sufficient FIFO entries for the latency of the remote
 -* UART to respond.  IOW, at least 32 bytes of FIFO.
 +* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
 +* AFE if hw flow control is supported
  */
 -   if (up-capabilities  UART_CAP_AFE  port-fifosize = 32) {
 +   if ((up-capabilities  UART_CAP_AFE  (port-fifosize = 32)) ||
 +   (port-flags  UPF_HARD_FLOW)) {
 up-mcr = ~UART_MCR_AFE;
 if (termios-c_cflag  CRTSCTS)
 up-mcr |= UART_MCR_AFE;
 diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
 index 9924660..77ec6a1 100644
 --- a/drivers/tty/serial/of_serial.c
 +++ b/drivers/tty/serial/of_serial.c
 @@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct 
 platform_device *ofdev)
   auto-flow-control))
 port8250.capabilities |= UART_CAP_AFE;

 +   if (of_property_read_bool(ofdev-dev.of_node,
 + has-hw-flow-control))
 +   port8250.port.flags |= UPF_HARD_FLOW;
 +
 ret = serial8250_register_8250_port(port8250);
 break;
 }
 diff --git a/drivers/tty/serial/serial_core.c 
 b/drivers/tty/serial/serial_core.c
 index b68550d..851707a 100644
 --- a/drivers/tty/serial/serial_core.c
 +++ b/drivers/tty/serial/serial_core.c
 @@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty, 
 struct uart_state *state,
 if (tty-termios.c_cflag  CBAUD)
 uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
 }
 -
 -   if (tty_port_cts_enabled(port)) {
 +   /*
 +* if hw support flow control without software intervention,
 +* then skip the below check
 +*/
 +   if (tty_port_cts_enabled(port) 
 +   !(uport-flags

Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller

[Dann Frazier]

On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar tinam...@apm.com wrote:
 This patch adds support for AppliedMicro X-Gene PCIe host controller. The
 driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
 cards.

 X-Gene PCIe controller driver has depedency on the pcie arch support for
 arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
 and approach for arch support is under discussion with arm64 maintainers.
 The reference patch can be found here -- https://lkml.org/lkml/2013/10/23/244

The reference patch looks corrupted (pcibios.c has no includes, etc),
would you mind reposting?

  -dann

 If someone wishes to test PCIe on X-Gene, arch support patch must be applied
 before the patches in this patch set.

 changes since V2:
 1. redefined each PCI port in different PCI domain correctly.
 2. removed setup_lane and setup_link functions from driver.
 3. removed scan_bus wrapper and set_primary_bus hack.
 4. added pci_ioremap_io for io resources.

 changes since V1:
 1. added PCI domain support
 2. reading cpu and pci addresses from device tree to configure regions.
 3. got rid of unnecessary wrappers for readl and writel.
 4. got rid of endpoint configuration code.
 5. added 'dma-ranges' property support to read inbound region configuration.
 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
 7. dropped 'clock-names' property from bindings
 8. added comments whereever requested.

 Tanmay Inamdar (4):
   pci: APM X-Gene PCIe controller driver
   arm64: dts: APM X-Gene PCIe device tree nodes
   dt-bindings: pci: xgene pcie device tree bindings
   MAINTAINERS: entry for APM X-Gene PCIe host driver

  .../devicetree/bindings/pci/xgene-pci.txt  |   52 ++
  MAINTAINERS|7 +
  arch/arm64/boot/dts/apm-mustang.dts|8 +
  arch/arm64/boot/dts/apm-storm.dtsi |  155 
  drivers/pci/host/Kconfig   |   10 +
  drivers/pci/host/Makefile  |1 +
  drivers/pci/host/pci-xgene.c   |  784 
 
  7 files changed, 1017 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
  create mode 100644 drivers/pci/host/pci-xgene.c

 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-pci in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

[Dann Frazier]

On Fri, Jun 20, 2014 at 5:18 PM, Iyappan Subramanian
isubraman...@apm.com wrote:
 This patch adds network driver for APM X-Gene SoC ethernet.

 Signed-off-by: Iyappan Subramanian isubraman...@apm.com
 Signed-off-by: Ravi Patel rapa...@apm.com
 Signed-off-by: Keyur Chudgar kchud...@apm.com
 ---
  drivers/net/ethernet/Kconfig   |   1 +
  drivers/net/ethernet/Makefile  |   1 +
  drivers/net/ethernet/apm/Kconfig   |   1 +
  drivers/net/ethernet/apm/Makefile  |   5 +
  drivers/net/ethernet/apm/xgene/Kconfig |   9 +
  drivers/net/ethernet/apm/xgene/Makefile|   6 +
  .../net/ethernet/apm/xgene/xgene_enet_ethtool.c| 125 +++
  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 848 +++
  drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 394 +
  drivers/net/ethernet/apm/xgene/xgene_enet_main.c   | 939 
 +
  drivers/net/ethernet/apm/xgene/xgene_enet_main.h   | 109 +++
  11 files changed, 2438 insertions(+)
  create mode 100644 drivers/net/ethernet/apm/Kconfig
  create mode 100644 drivers/net/ethernet/apm/Makefile
  create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig
  create mode 100644 drivers/net/ethernet/apm/xgene/Makefile
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c
  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h
[...]
 +static struct xgene_enet_desc_ring *xgene_enet_create_desc_ring(
 +   struct net_device *ndev, u32 ring_num,
 +   enum xgene_enet_ring_cfgsize cfgsize, u32 ring_id)
 +{
 +   struct xgene_enet_desc_ring *ring;
 +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 +   struct device *dev = pdata-pdev-dev;
 +   u32 size;
 +
 +   ring = devm_kzalloc(dev, sizeof(struct xgene_enet_desc_ring),
 +   GFP_KERNEL);
 +   if (!ring)
 +   return NULL;
 +
 +   ring-ndev = ndev;
 +   ring-num = ring_num;
 +   ring-cfgsize = cfgsize;
 +   ring-id = ring_id;
 +
 +   size = xgene_enet_get_ring_size(dev, cfgsize);
 +   ring-desc_addr = dma_zalloc_coherent(dev, size, ring-dma,
 + GFP_KERNEL);

Iyappan,
When testing this driver on a 3.16-rc2 base, I'm finding that
desc_addr gets assigned to NULL here, which results in an oops later
on (see below).

I wasn't seeing this before (3.15 base), so I'm guessing something
changed upstream, or in my config, to change this behavior. But it
does illuminate a place where we could maybe use some better error
handling (also see below).

 +   if (!ring-desc_addr)
 +   goto err;
 +   ring-size = size;
 +
 +   ring-cmd_base = pdata-ring_cmd_addr + (ring-num  6);
 +   ring-cmd = ring-cmd_base + INC_DEC_CMD_ADDR;
 +   pdata-rm = RM3;
 +   ring = xgene_enet_setup_ring(ring);
 +   netdev_dbg(ndev, ring info: num=%d  size=%d  id=%d  slots=%d\n,
 +  ring-num, ring-size, ring-id, ring-slots);
 +
 +   return ring;
 +err:
 +   dma_free_coherent(dev, size, ring-desc_addr, ring-dma);
 +   devm_kfree(dev, ring);
 +
 +   return NULL;
 +}
 +
 +static u16 xgene_enet_get_ring_id(enum xgene_ring_owner owner, u8 bufnum)
 +{
 +   return (owner  6) | (bufnum  GENMASK(5, 0));
 +}
 +
 +static int xgene_enet_create_desc_rings(struct net_device *ndev)
 +{
 +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 +   struct device *dev = pdata-pdev-dev;
 +   struct xgene_enet_desc_ring *rx_ring, *tx_ring, *cp_ring;
 +   struct xgene_enet_desc_ring *buf_pool = NULL;
 +   u8 cpu_bufnum = 0, eth_bufnum = 0;
 +   u8 bp_bufnum = 0x20;
 +   u16 ring_id, ring_num = 0;
 +   int ret;
 +
 +   /* allocate rx descriptor ring */
 +   ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
 +   rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
 + RING_CFGSIZE_16KB, ring_id);
 +   if (IS_ERR_OR_NULL(rx_ring)) {
 +   ret = PTR_ERR(rx_ring);
 +   goto err;
 +   }

Here we test for IS_ERR_OR_NULL. In the oops I'm hitting, rx_ring is
NULL here - but PTR_ERR() apparently returns 0 in that case. So this
function ends up returning no error.

 +   /* allocate buffer pool for receiving packets */
 +   ring_id = xgene_enet_get_ring_id(RING_OWNER_ETH0, bp_bufnum++);
 +   buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
 +  RING_CFGSIZE_2KB, ring_id);
 +   if (IS_ERR_OR_NULL(buf_pool)) {
 +   ret = PTR_ERR(buf_pool);
 +   goto err;
 +   }
 +
 +   

lustre virtual block device doesn't build w/ CONFIG_ARM64_64K_PAGES=y

[dann frazier]

With current git, lustre fails to build with CONFIG_ARM64_64K_PAGES=y
and CONFIG_LUSTRE_LLITE_LLOOP=m:

make -f scripts/Makefile.build obj=drivers/staging/lustre/lustre/llite
  gcc -Wp,-MD,drivers/staging/lustre/lustre/llite/.lloop.o.d  -nostdinc 
-isystem /usr/lib/gcc/aarch64-linux-gnu/4.8/include -I./arch/arm64/include 
-Iarch/arm64/include/generated  -Iinclude -I./arch/arm64/include/uapi 
-Iarch/arm64/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi 
-include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef 
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -Wno-format-security -mgeneral-regs-only 
-fno-delete-null-pointer-checks -O2 -Wframe-larger-than=1024 
-fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer 
-fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign 
-fno-strict-overflow -fconserve-stack -Werror=implicit-int 
-Werror=strict-prototypes -Idrivers/staging/lustre/include/ 
-Idrivers/staging/lustre/lustre/llite/../include  -DMODULE  
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(lloop)  
-DKBUILD_MODNAME=KBUILD_STR(llite_lloop) -c -o 
drivers/staging/lustre/lustre/llite/.tmp_lloop.o 
drivers/staging/lustre/lustre/llite/lloop.c
drivers/staging/lustre/lustre/llite/lloop.c: In function ‘loop_set_fd’:
drivers/staging/lustre/lustre/llite/lloop.c:523:78: error: duplicate case value
  CLASSERT(PAGE_CACHE_SIZE  (1  (sizeof(unsigned short) * 8)));
  ^
drivers/staging/lustre/lustre/llite/lloop.c:523:18: error: previously used here
  CLASSERT(PAGE_CACHE_SIZE  (1  (sizeof(unsigned short) * 8)));
  ^
scripts/Makefile.build:257: recipe for target 
'drivers/staging/lustre/lustre/llite/lloop.o' failed
make[5]: *** [drivers/staging/lustre/lustre/llite/lloop.o] Error 1
scripts/Makefile.build:404: recipe for target 
'drivers/staging/lustre/lustre/llite' failed
make[4]: *** [drivers/staging/lustre/lustre/llite] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging/lustre/lustre' 
failed
make[3]: *** [drivers/staging/lustre/lustre] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging/lustre' failed
make[2]: *** [drivers/staging/lustre] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging' failed
make[1]: *** [drivers/staging] Error 2
Makefile:893: recipe for target 'drivers' failed
make: *** [drivers] Error 2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] tools: testing: selftests: mq_perf_tests: Fix infinite loop on ARM

[dann frazier]

We can't use a char type to check for a negative return value since char
isn't guaranteed to be signed. Indeed, the char type tends to be unsigned on
ARM.

Signed-off-by: dann frazier dann.fraz...@canonical.com
---
 tools/testing/selftests/mqueue/mq_perf_tests.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/testing/selftests/mqueue/mq_perf_tests.c 
b/tools/testing/selftests/mqueue/mq_perf_tests.c
index 94dae65..8519e9e 100644
--- a/tools/testing/selftests/mqueue/mq_perf_tests.c
+++ b/tools/testing/selftests/mqueue/mq_perf_tests.c
@@ -536,10 +536,9 @@ int main(int argc, char *argv[])
 {
struct mq_attr attr;
char *option, *next_option;
-   int i, cpu;
+   int i, cpu, rc;
struct sigaction sa;
poptContext popt_context;
-   char rc;
void *retval;
 
main_thread = pthread_self();
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote:
 This patch adds syscon poweroff device node to support poweroff feature
 on APM X-Gene Mustang platform

hey Tai,
 The reboot changes work just fine for me, but poweroff does not:

[  OK  ] Reached target Final Step.
 Starting Power-Off...
reboot: Power down
Unable to poweroff system
Kernel panic - not syncing: Attempted to kill init! exitcode=0x

CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
Hardware name: APM X-Gene Mustang board (DT)
Call trace:
[ffc8990c] dump_backtrace+0x0/0x11c
[ffc89a38] show_stack+0x10/0x1c
[ffc0005b447c] dump_stack+0x88/0xc8
[ffc0005b3374] panic+0xe0/0x220
[ffcb5f24] do_exit+0x990/0x994
[ffcd06bc] SyS_reboot+0x14c/0x208
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x

  -dann

 Signed-off-by: Tai Nguyen ttngu...@apm.com
 ---
  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
 b/arch/arm64/boot/dts/apm/apm-mustang.dts
 index 83578e7..910d561 100644
 --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
 +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
 @@ -23,6 +23,18 @@
 device_type = memory;
 reg =  0x1 0x 0x0 0x8000 ; /* Updated by 
 bootloader */
 };
 +
 +   poweroff_mbox: poweroff_mbox@10548000 {
 +   compatible = syscon;
 +   reg = 0x0 0x10548000 0x0 0x30;
 +   };
 +
 +   poweroff: poweroff@10548010 {
 +   compatible = syscon-poweroff;
 +   regmap = poweroff_mbox;
 +   offset = 0x10;
 +   mask = 0x1;
 +   };
  };

  pcie0clk {
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen ttngu...@apm.com wrote:
 Hi Dann,

 On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier dann.fraz...@canonical.com 
 wrote:
 On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote:
 This patch adds syscon poweroff device node to support poweroff feature
 on APM X-Gene Mustang platform

 hey Tai,
  The reboot changes work just fine for me, but poweroff does not:

 [  OK  ] Reached target Final Step.
  Starting Power-Off...
 reboot: Power down
 Unable to poweroff system
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x

 CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
 Hardware name: APM X-Gene Mustang board (DT)
 Call trace:
 [ffc8990c] dump_backtrace+0x0/0x11c
 [ffc89a38] show_stack+0x10/0x1c
 [ffc0005b447c] dump_stack+0x88/0xc8
 [ffc0005b3374] panic+0xe0/0x220
 [ffcb5f24] do_exit+0x990/0x994
 [ffcd06bc] SyS_reboot+0x14c/0x208
 ---[ end Kernel panic - not syncing: Attempted to kill init! 
 exitcode=0x

   -dann


 Thanks for testing my patches.
 On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
 It requires a firmware update to support power off feature.
 May I ask what firmware version you're running on?

Sure, 1.15.12.

  -dann

 Tai


 Signed-off-by: Tai Nguyen ttngu...@apm.com
 ---
  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
 b/arch/arm64/boot/dts/apm/apm-mustang.dts
 index 83578e7..910d561 100644
 --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
 +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
 @@ -23,6 +23,18 @@
 device_type = memory;
 reg =  0x1 0x 0x0 0x8000 ; /* Updated by 
 bootloader */
 };
 +
 +   poweroff_mbox: poweroff_mbox@10548000 {
 +   compatible = syscon;
 +   reg = 0x0 0x10548000 0x0 0x30;
 +   };
 +
 +   poweroff: poweroff@10548010 {
 +   compatible = syscon-poweroff;
 +   regmap = poweroff_mbox;
 +   offset = 0x10;
 +   mask = 0x1;
 +   };
  };

  pcie0clk {
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



 --
 Tai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2 RESEND] power: reset: Add syscon reboot device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote:
 This patch adds syscon reboot device node to support reboot feature on APM 
 X-Gene platform

Tested-by: dann frazier dann.fraz...@canonical.com

 Signed-off-by: Feng Kan  f...@apm.com
 Signed-off-by: Tai Nguyen ttngu...@apm.com
 ---
  arch/arm64/boot/dts/apm/apm-storm.dtsi |   12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
 b/arch/arm64/boot/dts/apm/apm-storm.dtsi
 index c8d3e0e..16efcf7 100644
 --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
 +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
 @@ -710,5 +710,17 @@
 dma-coherent;
 clocks = dmaclk 0;
 };
 +
 +   scu: system-clk-controller@1700 {
 +   compatible = apm,xgene-scu,syscon;
 +   reg = 0x0 0x1700 0x0 0x400;
 +   };
 +
 +   reboot: reboot@1714 {
 +   compatible = syscon-reboot;
 +   regmap = scu;
 +   offset = 0x14;
 +   mask = 0x1;
 +   };
 };
  };
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform

[Dann Frazier]

On Tue, Jun 9, 2015 at 9:31 AM, Dann Frazier dann.fraz...@canonical.com wrote:
 On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen ttngu...@apm.com wrote:
 Hi Dann,

 On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier dann.fraz...@canonical.com 
 wrote:
 On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen ttngu...@apm.com wrote:
 This patch adds syscon poweroff device node to support poweroff feature
 on APM X-Gene Mustang platform

 hey Tai,
  The reboot changes work just fine for me, but poweroff does not:

 [  OK  ] Reached target Final Step.
  Starting Power-Off...
 reboot: Power down
 Unable to poweroff system
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x

 CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW   4.1.0-rc7+ #1
 Hardware name: APM X-Gene Mustang board (DT)
 Call trace:
 [ffc8990c] dump_backtrace+0x0/0x11c
 [ffc89a38] show_stack+0x10/0x1c
 [ffc0005b447c] dump_stack+0x88/0xc8
 [ffc0005b3374] panic+0xe0/0x220
 [ffcb5f24] do_exit+0x990/0x994
 [ffcd06bc] SyS_reboot+0x14c/0x208
 ---[ end Kernel panic - not syncing: Attempted to kill init! 
 exitcode=0x

   -dann


 Thanks for testing my patches.
 On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
 It requires a firmware update to support power off feature.
 May I ask what firmware version you're running on?

 Sure, 1.15.12.

Tai worked with me offline. For reference, this requires an updated
SlimPro firmware in addition to the u-boot update. Verified it works
for me after the update, so:

Tested-by: dann frazier dann.fraz...@canoncial.com

   -dann

 Tai


 Signed-off-by: Tai Nguyen ttngu...@apm.com
 ---
  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  1 file changed, 12 insertions(+)

 diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts 
 b/arch/arm64/boot/dts/apm/apm-mustang.dts
 index 83578e7..910d561 100644
 --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
 +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
 @@ -23,6 +23,18 @@
 device_type = memory;
 reg =  0x1 0x 0x0 0x8000 ; /* Updated by 
 bootloader */
 };
 +
 +   poweroff_mbox: poweroff_mbox@10548000 {
 +   compatible = syscon;
 +   reg = 0x0 0x10548000 0x0 0x30;
 +   };
 +
 +   poweroff: poweroff@10548010 {
 +   compatible = syscon-poweroff;
 +   regmap = poweroff_mbox;
 +   offset = 0x10;
 +   mask = 0x1;
 +   };
  };

  pcie0clk {
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



 --
 Tai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm64: Disallow combination of ARCH_XGENE and 16K page size

[dann frazier]

16K page size is an optional feature of the architecture, and is not
supported by the X-Gene SoC family.

Signed-off-by: dann frazier <dann.fraz...@canonical.com>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..b241290 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -133,6 +133,7 @@ config ARCH_VEXPRESS
 
 config ARCH_XGENE
bool "AppliedMicro X-Gene SOC Family"
+   depends on !ARM64_16K_PAGES
help
  This enables support for AppliedMicro X-Gene SOC Family
 
-- 
2.7.0

Re: [PATCH v2 06/18] arm64: arch_timer: Add infrastructure for multiple erratum detection methods

[dann frazier]

On Mon, Mar 20, 2017 at 11:48 AM, Marc Zyngier  wrote:
> We're currently stuck with DT when it comes to handling errata, which
> is pretty restrictive. In order to make things more flexible, let's
> introduce an infrastructure that could support alternative discovery
> methods. No change in functionality.
>
> Reviewed-by: Hanjun Guo 
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/include/asm/arch_timer.h  |  7 +++-
>  drivers/clocksource/arm_arch_timer.c | 80 
> +++-
>  2 files changed, 75 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h 
> b/arch/arm64/include/asm/arch_timer.h
> index b4b34004a21e..5cd964e90d11 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -37,9 +37,14 @@ extern struct static_key_false arch_timer_read_ool_enabled;
>  #define needs_unstable_timer_counter_workaround()  false
>  #endif
>
> +enum arch_timer_erratum_match_type {
> +   ate_match_dt,
> +};
>
>  struct arch_timer_erratum_workaround {
> -   const char *id; /* Indicate the Erratum ID */
> +   enum arch_timer_erratum_match_type match_type;
> +   const void *id;
> +   const char *desc;
> u32 (*read_cntp_tval_el0)(void);
> u32 (*read_cntv_tval_el0)(void);
> u64 (*read_cntvct_el0)(void);
> diff --git a/drivers/clocksource/arm_arch_timer.c 
> b/drivers/clocksource/arm_arch_timer.c
> index 7a8a4117f123..6a0f0e161a0f 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -182,7 +182,9 @@ EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
>  static const struct arch_timer_erratum_workaround ool_workarounds[] = {
>  #ifdef CONFIG_FSL_ERRATUM_A008585
> {
> +   .match_type = ate_match_dt,
> .id = "fsl,erratum-a008585",
> +   .desc = "Freescale erratum a005858",
> .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
> .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
> .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
> @@ -190,13 +192,78 @@ static const struct arch_timer_erratum_workaround 
> ool_workarounds[] = {
>  #endif
>  #ifdef CONFIG_HISILICON_ERRATUM_161010101
> {
> +   .match_type = ate_match_dt,
> .id = "hisilicon,erratum-161010101",
> +   .desc = "HiSilicon erratum 161010101",
> .read_cntp_tval_el0 = hisi_161010101_read_cntp_tval_el0,
> .read_cntv_tval_el0 = hisi_161010101_read_cntv_tval_el0,
> .read_cntvct_el0 = hisi_161010101_read_cntvct_el0,
> },
>  #endif
>  };
> +
> +typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *,
> +  const void *);
> +
> +static
> +bool arch_timer_check_dt_erratum(const struct arch_timer_erratum_workaround 
> *wa,
> +const void *arg)
> +{
> +   const struct device_node *np = arg;
> +
> +   return of_property_read_bool(np, wa->id);
> +}
> +
> +static const struct arch_timer_erratum_workaround *
> +arch_timer_iterate_errata(enum arch_timer_erratum_match_type type,
> + ate_match_fn_t match_fn,
> + void *arg)
> +{
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(ool_workarounds); i++) {
> +   if (ool_workarounds[i].match_type != type)
> +   continue;
> +
> +   if (match_fn(_workarounds[i], arg))
> +   return _workarounds[i];
> +   }
> +
> +   return NULL;
> +}
> +
> +static
> +void arch_timer_enable_workaround(const struct arch_timer_erratum_workaround 
> *wa)
> +{
> +   timer_unstable_counter_workaround = wa;
> +   static_branch_enable(_timer_read_ool_enabled);
> +}
> +
> +static void arch_timer_check_ool_workaround(enum 
> arch_timer_erratum_match_type type,
> +   void *arg)
> +{
> +   const struct arch_timer_erratum_workaround *wa;
> +   ate_match_fn_t match_fn = NULL;
> +
> +   if (static_branch_unlikely(_timer_read_ool_enabled))
> +   return;
> +
> +   switch (type) {
> +   case ate_match_dt:
> +   match_fn = arch_timer_check_dt_erratum;
> +   break;

hey Marc,
   Would it make sense to have a default case here that warns &
returns? That wouldn't get hit by this series as-is, but might avoid a
NULL callback in the future.

  -dann

> +   }
> +
> +   wa = arch_timer_iterate_errata(type, match_fn, arg);
> +   if (!wa)
> +   return;
> +
> +   arch_timer_enable_workaround(wa);
> +   pr_info("Enabling global workaround for %s\n", wa->desc);
> +}
> +
> +#else
> +#define arch_timer_check_ool_workaround(t,a)   do { } while(0)
>  #endif /* 

Re: [PATCH V7 2/7] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Sun, Mar 12, 2017 at 8:42 PM, zhichang.yuan
 wrote:
> After introducing the new generic I/O space management(LIBIO), the original 
> PCI
> MMIO relevant helpers need to be updated based on the new interfaces defined 
> in
> LIBIO.
> This patch adapts the corresponding code to match the changes introduced by
> LIBIO.
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann #earlier draft
> Acked-by: Bjorn Helgaas    #drivers/pci parts
> ---
>  drivers/acpi/pci_root.c |  8 +++--
>  drivers/of/address.c|  4 ++-
>  drivers/pci/pci.c   | 96 
> +++--
>  include/linux/pci.h |  3 +-
>  4 files changed, 30 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 919be0a..4d8cc24 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct 
> device *dev,
> }
>  }
>
> -static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
> +static void acpi_pci_root_remap_iospace(struct fwnode_handle *fwnode,
> +   struct resource_entry *entry)
>  {
>  #ifdef PCI_IOBASE
> struct resource *res = entry->res;
> @@ -739,7 +740,7 @@ static void acpi_pci_root_remap_iospace(struct 
> resource_entry *entry)
> resource_size_t length = resource_size(res);
> unsigned long port;
>
> -   if (pci_register_io_range(cpu_addr, length))
> +   if (pci_register_io_range(fwnode, cpu_addr, length))
> goto err;
>
> port = pci_address_to_pio(cpu_addr);
> @@ -781,7 +782,8 @@ int acpi_pci_probe_root_resources(struct 
> acpi_pci_root_info *info)
> else {
> resource_list_for_each_entry_safe(entry, tmp, list) {
> if (entry->res->flags & IORESOURCE_IO)
> -   acpi_pci_root_remap_iospace(entry);
> +   acpi_pci_root_remap_iospace(>fwnode,
> +   entry);
>
> if (entry->res->flags & IORESOURCE_DISABLED)
> resource_list_destroy_entry(entry);
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..fb5d16a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -2,6 +2,7 @@
>  #define pr_fmt(fmt)"OF: " fmt
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -323,7 +324,8 @@ int of_pci_range_to_resource(struct of_pci_range *range,
>
> if (res->flags & IORESOURCE_IO) {
> unsigned long port;
> -   err = pci_register_io_range(range->cpu_addr, range->size);
> +   err = pci_register_io_range(>fwnode, range->cpu_addr,
> +   range->size);
> if (err)
> goto invalid_range;
> port = pci_address_to_pio(range->cpu_addr);
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..079319f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3238,65 +3238,37 @@ int pci_request_regions_exclusive(struct pci_dev 
> *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> -#ifdef PCI_IOBASE
> -struct io_range {
> -   struct list_head list;
> -   phys_addr_t start;
> -   resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
>  /*
>   * Record the PCI IO range (expressed as CPU physical address + size).
>   * Return a negative value if an error has occured, zero otherwise
>   */
> -int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
> +   resource_size_t size)
>  {
> int err = 0;
>
>  #ifdef PCI_IOBASE
> -   struct io_range *range;
> -   resource_size_t allocated_size = 0;
> -
> -   /* check if the range hasn't been previously recorded */
> -   spin_lock(_range_lock);
> -   list_for_each_entry(range, _range_list, list) {
> -   if (addr >= range->start && addr + size <= range->start + 
> size) {
> -   /* range already registered, bail out */
> -   goto end_register;
> -   }
> -   allocated_size += range->size;
> -   }
> -
> -   /* range not registed yet, check for available space */
> -   if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> -   /* if it's too big check if 64K space can be reserved */
> -   if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> -   err = -E2BIG;
> -   goto end_register;
> -   }
> + 

Re: [PATCH V8 0/7] LPC: legacy ISA I/O support

[dann frazier]

ycon;
>
> V7 thread here: https://lkml.org/lkml/2017/3/12/279
> v6 thread here: https://lkml.org/lkml/2017/1/24/25
> v5 thread here: https://lkml.org/lkml/2016/11/7/955
> v4 thread here: https://lkml.org/lkml/2016/10/20/149
> v3 thread here: https://lkml.org/lkml/2016/9/14/326
> v2 thread here: https://lkml.org/lkml/2016/9/7/356
> v1 thread here: https://lkml.org/lkml/2015/12/29/154
>
>
> Signed-off-by: Zhichang Yuan <yuanzhich...@hisilicon.com>
> zhichang.yuan (6):
>   LIBIO: Introduce a generic PIO mapping method
>   PCI: Apply the new generic I/O management on PCI IO hosts
>   OF: Add missing I/O range exception for indirect-IO devices
>   LPC: Support the device-tree LPC host on Hip06/Hip07
>   ACPI: Support the probing on the devices which apply indirect-IO
>   LPC: Add the ACPI LPC support
>
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  MAINTAINERS|   8 +
>  arch/arm64/boot/dts/hisilicon/hip06-d03.dts|   4 +
>  arch/arm64/boot/dts/hisilicon/hip06.dtsi   |  14 +
>  arch/arm64/boot/dts/hisilicon/hip07-d05.dts|   4 +
>  arch/arm64/boot/dts/hisilicon/hip07.dtsi   |  14 +
>  drivers/acpi/Makefile  |   1 +
>  drivers/acpi/acpi_indirectio.c | 344 +
>  drivers/acpi/internal.h|   5 +
>  drivers/acpi/pci_root.c|   8 +-
>  drivers/acpi/scan.c|   1 +
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 547 
> +
>  drivers/of/address.c   |  95 +++-
>  drivers/pci/pci.c  | 104 +---
>  include/asm-generic/io.h   |  50 ++
>  include/linux/logic_pio.h  | 174 +++
>  include/linux/pci.h|   3 +-
>  lib/Kconfig|  26 +
>  lib/Makefile   |   2 +
>  lib/logic_pio.c| 413 
>  22 files changed, 1758 insertions(+), 102 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/acpi/acpi_indirectio.c
>  create mode 100644 drivers/bus/hisi_lpc.c
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c

Booted up on a D05, was able to use the LPC-connected IPMI interface.

Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO

[dann frazier]

On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
 wrote:
> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
> with some special host-local I/O ports known on x86. To access the I/O
> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
> registered before probing the downstream devices and set up the I/O mapping.
> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>
> This patch introdueces a new ACPI handler for this device category. Through 
> the
> handler attach callback, the indirect-IO hosts I/O registration is done and
> all peripherals' I/O resources are translated into logic/fake PIO before
> starting the enumeration.
>
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> ---
>  drivers/acpi/Makefile  |   1 +
>  drivers/acpi/acpi_indirectio.c | 344 
> +
>  drivers/acpi/internal.h|   5 +
>  drivers/acpi/scan.c|   1 +
>  4 files changed, 351 insertions(+)
>  create mode 100644 drivers/acpi/acpi_indirectio.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index a391bbc..10e5f2b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
>  acpi-y += acpi_lpat.o
>  acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
>  acpi-$(CONFIG_ACPI_WATCHDOG)   += acpi_watchdog.o
> +acpi-$(CONFIG_INDIRECT_PIO)+= acpi_indirectio.o
>
>  # These are (potentially) separate modules
>
> diff --git a/drivers/acpi/acpi_indirectio.c b/drivers/acpi/acpi_indirectio.c
> new file mode 100644
> index 000..c8c80b5
> --- /dev/null
> +++ b/drivers/acpi/acpi_indirectio.c
> @@ -0,0 +1,344 @@
> +/*
> + * ACPI support for indirect-IO bus.
> + *
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "internal.h"
> +
> +ACPI_MODULE_NAME("indirect IO");
> +
> +#define INDIRECT_IO_INFO(desc) ((unsigned long))
> +
> +struct lpc_private_data {
> +   resource_size_t io_size;
> +   resource_size_t io_start;
> +};
> +
> +struct indirectio_device_desc {
> +   void *pdata; /* device relevant info data */
> +   int (*pre_setup)(struct acpi_device *adev, void *pdata);
> +};
> +
> +static struct lpc_private_data lpc_data = {
> +   .io_size = LPC_BUS_IO_SIZE,
> +   .io_start = LPC_MIN_BUS_RANGE,
> +};
> +
> +static inline bool acpi_logicio_supported_resource(struct acpi_resource *res)
> +{
> +   switch (res->type) {
> +   case ACPI_RESOURCE_TYPE_ADDRESS32:
> +   case ACPI_RESOURCE_TYPE_ADDRESS64:
> +   return true;
> +   }
> +   return false;
> +}
> +
> +static acpi_status acpi_count_logiciores(struct acpi_resource *res,
> +  void *data)
> +{
> +   int *res_cnt = data;
> +
> +   if (acpi_logicio_supported_resource(res) &&
> +   !acpi_dev_filter_resource_type(res, IORESOURCE_IO))
> +   (*res_cnt)++;
> +
> +   return AE_OK;
> +}
> +
> +static acpi_status acpi_read_one_logiciores(struct acpi_resource *res,
> +   void *data)
> +{
> +   struct acpi_resource **resource = data;
> +
> +   if (acpi_logicio_supported_resource(res) &&
> +   !acpi_dev_filter_resource_type(res, IORESOURCE_IO)) {
> +   memcpy((*resource), res, sizeof(struct acpi_resource));
> +   (*resource)->length = sizeof(struct acpi_resource);
> +   (*resource)->type = res->type;
> +   (*resource)++;
> +   }
> +
> +   return AE_OK;
> +}
> +
> +static acpi_status
> +acpi_build_logiciores_template(struct acpi_device *adev,
> +   struct acpi_buffer *buffer)
> +{
> +   acpi_handle handle = adev->handle;
> +   struct acpi_resource *resource;
> +   acpi_status status;
> +   int res_cnt = 0;
> +
> +   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +acpi_count_logiciores, _cnt);
> +   if (ACPI_FAILURE(status) || !res_cnt) {
> +   dev_err(>dev, "can't evaluate _CRS: %d\n", status);
> +   return -EINVAL;
> +   }
> +
> +   buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
> +   buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);

(Seth Forshee noticed this issue, just passing it on)

Should this just 

Re: [PATCH 00/17] clocksource/arch_timer: Errara workaround infrastructure rework

[dann frazier]

On Mon, Mar 6, 2017 at 4:26 AM, Marc Zyngier <marc.zyng...@arm.com> wrote:
> It has recently become obvious that a number of arm64 systems have
> been blessed with a set of timers that are slightly less than perfect,
> and require a bit of hand-holding. We already have a bunch of
> errata-specific code to deal with this, but as we're adding more
> potential detection methods (DT, ACPI, capability), things are getting
> a bit out of hands.
>
> Instead of adding more ad-hoc fixes to an already difficult code base,
> let's give ourselves a bit of an infrastructure that can deal with
> this and hide most of the uggliness behind frendly accessors.
>
> The series is structured as such:
>
> - The first half of the series rework the existing workarounds,
>   allowing errata to be matched using a given detection method
>
> - Another patch allows a workaround to affect a subset of the CPUs,
>   and not the whole system
>
> - Another set of patches allow the virtual counter to be trapped when
>   accessed from userspace (something that affects the current set of
>   broken platform, and that is not worked around yet)
>
> - We then work around a Cortex-A73 erratum, whose counter can return a
>   wrong value if read while crossing a 32bit boundary
>
> - Finally, we add some ACPI-specific workarounds for HiSilicon
>   platforms that have the HISILICON_ERRATUM_161010101 defect.
>
> Note that so far, we only deal with arm64. Once the infrastructure is
> agreed upon, we can look at generalizing it (to some extent) to 32bit
> ARM (typical use case would be a 32bit guest running on an affected
> host).

Thanks Marc. Worked on our HiSilicon board:

[0.00] arm_arch_timer: Enabling global workaround for
HiSilicon erratum 161010101
[0.00] arm_arch_timer: CPU0: Trapping CNTVCT access
[0.00] arm_arch_timer: Architected cp15 timer(s) running at
50.00MHz (phys).
[0.266571] arm_arch_timer: CPU1: Trapping CNTVCT access
[0.270108] arm_arch_timer: CPU2: Trapping CNTVCT access
[...]

Tested-by: dann frazier <dann.fraz...@canonical.com>

  -dann

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

On Mon, Oct 23, 2017 at 3:08 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote:
> On Mon, 2017-10-23 at 09:41 -0600, dann frazier wrote:
>> (gdb) list *(sg_io+0x120)
>> 0x084e71a8 is in sg_io (./include/linux/uaccess.h:113).
>> 108   static inline unsigned long
>> 109   _copy_from_user(void *to, const void __user *from, unsigned long n)
>> 110   {
>> 111   unsigned long res = n;
>> 112   might_fault();
>> 113   if (likely(access_ok(VERIFY_READ, from, n))) {
>> 114   kasan_check_write(to, n);
>> 115   res = raw_copy_from_user(to, from, n);
>> 116   }
>> 117   if (unlikely(res))
>
> Hello Dann,
>
> Would it be possible to check whether the patch below is sufficient to fix 
> this?

hey Bart,
 Yes, it does appear to be sufficient:

ubuntu@ubuntu:~$ sudo dmesg -c > /dev/null
ubuntu@ubuntu:~$ sudo dmraid -r -c
ERROR: isw: seeking device "/dev/vda" to 18446744073708843520
ERROR: sil: seeking device "/dev/vda" to 18446744073709401600
no raid disks
ubuntu@ubuntu:~$ dmesg
ubuntu@ubuntu:~$

  -dann

Re: [PATCH v10 0/9] LPC: legacy ISA I/O support

[dann frazier]

On Fri, Oct 27, 2017 at 10:11 AM, Gabriele Paoloni
<gabriele.paol...@huawei.com> wrote:
> From: gabriele paoloni <gabriele.paol...@huawei.com>
>
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.

fwiw, I tested this on one of our D05 boards and verified that the
IPMI SI worked fine.

Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH v10 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

[dann frazier]

On Fri, Oct 27, 2017 at 05:11:24PM +0100, Gabriele Paoloni wrote:
> From: "zhichang.yuan" 
> 
> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
> I/O port addresses. This patch implements the LPC host controller driver
> which perform the I/O operations on the underlying hardware.
> We don't want to touch those existing peripherals' driver, such as ipmi-bt.
> So this driver applies the indirect-IO introduced in the previous patch
> after registering an indirect-IO node to the indirect-IO devices list which
> will be searched in the I/O accessors to retrieve the host-local I/O port.
> 
> Signed-off-by: Zou Rongrong 
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Rob Herring  #dts part
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 526 
> +
>  4 files changed, 569 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..213181f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,33 @@
> +Hisilicon Hip06 low-pin-count device
> +  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> +  provides I/O access to some legacy ISA devices.
> +  Hip06 is based on arm64 architecture where there is no I/O space. So, the
> +  I/O ports here are not cpu addresses, and there is no 'ranges' property in
> +  LPC device node.
> +
> +Required properties:
> +- compatible:  value should be as follows:
> + (a) "hisilicon,hip06-lpc"
> + (b) "hisilicon,hip07-lpc"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the LPC register set is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicon,hip06-lpc";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + };
> +};
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 2408ea3..358eed3 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -64,6 +64,15 @@ config BRCMSTB_GISB_ARB
> arbiter. This driver provides timeout and target abort error handling
> and internal bus master decoding.
>  
> +config HISILICON_LPC
> + bool "Support for ISA I/O space on Hisilicon Hip0X"
> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST))
> + select LOGIC_PIO
> + select INDIRECT_PIO
> + help
> +   Driver needed for some legacy ISA devices attached to Low-Pin-Count
> +   on Hisilicon Hip0X SoC.
> +
>  config IMX_WEIM
>   bool "Freescale EIM DRIVER"
>   depends on ARCH_MXC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index cc6364b..28e3862 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
>  obj-$(CONFIG_ARM_CCN)+= arm-ccn.o
>  
>  obj-$(CONFIG_BRCMSTB_GISB_ARB)   += brcmstb_gisb.o
> +obj-$(CONFIG_HISILICON_LPC)  += hisi_lpc.o
>  obj-$(CONFIG_IMX_WEIM)   += imx-weim.o
>  obj-$(CONFIG_MIPS_CDMM)  += mips_cdmm.o
>  obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> new file mode 100644
> index 000..c885483
> --- /dev/null
> +++ b/drivers/bus/hisi_lpc.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + * Author: Zou Rongrong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU 

[bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

hey,
  I'm seeing a regression when executing 'dmraid -r -c' in an arm64
QEMU guest, which I've bisected to the following commit:

  ca18d6f7 "block: Make most scsi_req_init() calls implicit"

I haven't yet had time to try and debug it yet, but wanted to get
the report out there before the weekend. Here's the crash:

[  138.519885] usercopy: kernel memory overwrite attempt detected to   
(null) () (6 bytes)
[  138.521562] kernel BUG at mm/usercopy.c:72!
[  138.522294] Internal error: Oops - BUG: 0 [#1] SMP
[  138.523105] Modules linked in: nls_utf8 isofs nls_iso8859_1 qemu_fw_cfg 
ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_decompress 
zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 
aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64 
sha1_ce virtio_net virtio_blk aes_neon_bs aes_neon_blk crypto_simd cryptd 
aes_arm64
[  138.531307] CPU: 62 PID: 2271 Comm: dmraid Not tainted 4.14.0-rc5+ #20
[  138.532512] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[  138.533796] task: 8003cba2e900 task.stack: 110e8000
[  138.534887] PC is at __check_object_size+0x114/0x200
[  138.535800] LR is at __check_object_size+0x114/0x200
[  138.536711] pc : [] lr : [] pstate: 
00400145
[  138.538073] sp : 110ebb00
[  138.538682] x29: 110ebb00 x28:  
[  138.539658] x27: d88e1110 x26: 8003e8d3d800 
[  138.540633] x25: 0802001d x24: 8003e1131920 
[  138.541621] x23: 0006 x22: 0006 
[  138.542596] x21:  x20: 0006 
[  138.543571] x19:  x18:  
[  138.544548] x17: 83380ce0 x16: 082dd3b0 
[  138.545525] x15: 093c8c08 x14: 6c756e2820202020 
[  138.546511] x13: 202020202020206f x12: 7420646574636574 
[  138.547489] x11: 093c9658 x10: 086ae800 
[  138.548466] x9 : 7265766f2079726f x8 : 0017 
[  138.549445] x7 : 6c756e3c2820296c x6 : 8003eeb51c28 
[  138.550434] x5 : 8003eeb51c28 x4 :  
[  138.551411] x3 : 8003eeb59ec8 x2 : d4a0cd0f45236000 
[  138.552388] x1 :  x0 : 0059 
[  138.553364] Process dmraid (pid: 2271, stack limit = 0x110e8000)
[  138.554593] Call trace:
[  138.555043] Exception stack(0x110eb9c0 to 0x110ebb00)
[  138.556214] b9c0: 0059  d4a0cd0f45236000 
8003eeb59ec8
[  138.557653] b9e0:  8003eeb51c28 8003eeb51c28 
6c756e3c2820296c
[  138.559082] ba00: 0017 7265766f2079726f 086ae800 
093c9658
[  138.560510] ba20: 7420646574636574 202020202020206f 6c756e2820202020 
093c8c08
[  138.561950] ba40: 082dd3b0 83380ce0  

[  138.563379] ba60: 0006  0006 
0006
[  138.564805] ba80: 8003e1131920 0802001d 8003e8d3d800 
d88e1110
[  138.566238] baa0:  110ebb00 082c0e5c 
110ebb00
[  138.567666] bac0: 082c0e5c 00400145 08e25a80 

[  138.569090] bae0: 0001 0006 110ebb00 
082c0e5c
[  138.570523] [] __check_object_size+0x114/0x200
[  138.571628] [] sg_io+0x120/0x438
[  138.572507] [] scsi_cmd_ioctl+0x594/0x728
[  138.573531] [] scsi_cmd_blk_ioctl+0x50/0x60
[  138.574594] [] virtblk_ioctl+0x60/0x80 [virtio_blk]
[  138.575769] [] blkdev_ioctl+0x5e4/0xb50
[  138.576756] [] block_ioctl+0x50/0x68
[  138.577698] [] do_vfs_ioctl+0xc4/0x940
[  138.578671] [] SyS_ioctl+0x8c/0xa8
[  138.579581] Exception stack(0x110ebec0 to 0x110ec000)
[  138.580752] bec0: 0005 2285 d88e10b8 
0006
[  138.582199] bee0:  0004 83416648 
0050
[  138.583623] bf00: 001d 0003 0012 
0011
[  138.585050] bf20: 83409000 00ff 8309dc70 
0531
[  138.586490] bf40: 8344a360 83380ce0 00dc 
83478948
[  138.587918] bf60: 0004 17ee7f90 0005 
17ede920
[  138.589346] bf80: 17ee7f60 0003 83416648 
17ee7f60
[  138.590785] bfa0: d88e1218 d88e1090 834166dc 
d88e1090
[  138.592215] bfc0: 83380cec 8000 0005 
001d
[  138.593649] bfe0:    

[  138.595091] [] el0_svc_naked+0x24/0x28
[  138.596071] Code: aa1403e5 aa1303e3 9119a0c0 97f9d96d (d421) 
[  138.597193] ---[ end trace b7eecd0b21001177 ]---

Here's the ioctl as 

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

On Fri, Oct 20, 2017 at 11:30:55PM +, Bart Van Assche wrote:
> On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote:
> > hey,
> >   I'm seeing a regression when executing 'dmraid -r -c' in an arm64
> > QEMU guest, which I've bisected to the following commit:
> > 
> >   ca18d6f7 "block: Make most scsi_req_init() calls implicit"
> > 
> > I haven't yet had time to try and debug it yet, but wanted to get
> > the report out there before the weekend. Here's the crash:
> > 
> > [  138.519885] usercopy: kernel memory overwrite attempt detected to
> >(null) () (6 bytes)
> > [  138.521562] kernel BUG at mm/usercopy.c:72!
> > [  138.522294] Internal error: Oops - BUG: 0 [#1] SMP
> > [  138.523105] Modules linked in: nls_utf8 isofs nls_iso8859_1 qemu_fw_cfg 
> > ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi 
> > scsi_transport_iscsi ip_tables
> > x_tables autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 
> > async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
> > libcrc32c raid1 raid0
> > multipath linear aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce 
> > sha2_ce sha256_arm64 sha1_ce virtio_net virtio_blk aes_neon_bs aes_neon_blk 
> > crypto_simd cryptd
> > aes_arm64
> > [  138.531307] CPU: 62 PID: 2271 Comm: dmraid Not tainted 4.14.0-rc5+ #20
> > [  138.532512] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
> > 02/06/2015
> > [  138.533796] task: 8003cba2e900 task.stack: 110e8000
> > [  138.534887] PC is at __check_object_size+0x114/0x200
> > [  138.535800] LR is at __check_object_size+0x114/0x200
> > [  138.536711] pc : [] lr : [] pstate: 
> > 00400145
> > [  138.538073] sp : 110ebb00
> > [  138.538682] x29: 110ebb00 x28:  
> > [  138.539658] x27: d88e1110 x26: 8003e8d3d800 
> > [  138.540633] x25: 0802001d x24: 8003e1131920 
> > [  138.541621] x23: 0006 x22: 0006 
> > [  138.542596] x21:  x20: 0006 
> > [  138.543571] x19:  x18:  
> > [  138.544548] x17: 83380ce0 x16: 082dd3b0 
> > [  138.545525] x15: 093c8c08 x14: 6c756e2820202020 
> > [  138.546511] x13: 202020202020206f x12: 7420646574636574 
> > [  138.547489] x11: 093c9658 x10: 086ae800 
> > [  138.548466] x9 : 7265766f2079726f x8 : 0017 
> > [  138.549445] x7 : 6c756e3c2820296c x6 : 8003eeb51c28 
> > [  138.550434] x5 : 8003eeb51c28 x4 :  
> > [  138.551411] x3 : 8003eeb59ec8 x2 : d4a0cd0f45236000 
> > [  138.552388] x1 :  x0 : 0059 
> > [  138.553364] Process dmraid (pid: 2271, stack limit = 0x110e8000)
> > [  138.554593] Call trace:
> > [  138.555043] Exception stack(0x110eb9c0 to 0x110ebb00)
> > [  138.556214] b9c0: 0059  d4a0cd0f45236000 
> > 8003eeb59ec8
> > [  138.557653] b9e0:  8003eeb51c28 8003eeb51c28 
> > 6c756e3c2820296c
> > [  138.559082] ba00: 0017 7265766f2079726f 086ae800 
> > 093c9658
> > [  138.560510] ba20: 7420646574636574 202020202020206f 6c756e2820202020 
> > 093c8c08
> > [  138.561950] ba40: 082dd3b0 83380ce0  
> > 
> > [  138.563379] ba60: 0006  0006 
> > 0006
> > [  138.564805] ba80: 8003e1131920 0802001d 8003e8d3d800 
> > d88e1110
> > [  138.566238] baa0:  110ebb00 082c0e5c 
> > 110ebb00
> > [  138.567666] bac0: 082c0e5c 00400145 08e25a80 
> > 
> > [  138.569090] bae0: 0001 0006 110ebb00 
> > 082c0e5c
> > [  138.570523] [] __check_object_size+0x114/0x200
> > [  138.571628] [] sg_io+0x120/0x438
> > [  138.572507] [] scsi_cmd_ioctl+0x594/0x728
> > [  138.573531] [] scsi_cmd_blk_ioctl+0x50/0x60
> > [  138.574594] [] virtblk_ioctl+0x60/0x80 [virtio_blk]
> > [  138.575769] [] blkdev_ioctl+0x5e4/0xb50
> > [  138.576756] [] block_ioctl+0x50/0x68
> > [  138.577698] [] do_vfs_ioctl+0xc4/0x940
> > [  138.578671] [] SyS_ioctl+0x8c/0xa8
> > [  138.579581] Exception stack(0x110ebec0 to 0x110ec000)
> > [  138.580752] bec0: 0005 2285 d88e10b8 
> > 0006
> > [  138.582199] bee0: 

Re: [PATCH v12 0/9] LPC: legacy ISA I/O support

[dann frazier]

On Tue, Jan 23, 2018 at 9:36 AM, John Garry <john.ga...@huawei.com> wrote:
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.
> ---
> | LPC host|
> | |
> ---
>  |
> _V___LPC
>   |   |
>   V   V
>  
>  |  BT(ipmi)|
>  
>
> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific
> LPC driver is needed to make LPC host generate the standard LPC I/O cycles 
> with
> the target peripherals'I/O port addresses. But on curent arm64 world, there is
> no real I/O accesses. All the I/O operations through in/out accessors are 
> based
> on MMIO ranges; on Hip06/Hip07 LPC the I/O accesses are performed through 
> driver
> specific accessors rather than MMIO.
> To solve this issue and keep the relevant existing peripherals' drivers 
> untouched,
> this patchset:
>- introduces a generic I/O space management framework, LIBIO, to support 
> I/O
>  operations on host controllers operating either on MMIO buses or on buses
>  requiring specific driver I/O accessors;
>- redefines the in/out accessors to provide a unified interface for both 
> MMIO
>  and driver specific I/O operations. Using LIBIO, th call of in/out() from
>  the host children drivers, such as ipmi-si, will be redirected to the
>  corresponding device-specific I/O hooks to perform the I/O accesses.
>
> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals 
> can
> be supported without any changes on the existing ipmi-si driver.
>
> The whole patchset has been tested on Hip07 D05 board both using DTB and ACPI.

fyi, tested successfully here as well on a D05:

Tested-by: dann frazier <dann.fraz...@canonical.com>

 -dann

> Differences to v11:
> - fixed build errors for i386, m68k, and tile
> - added a comment in LPC driver commit log why we set
>the kernel config as bool
> - some tidying logic_pio code
>
> Differences to v10:
> - dropped CONFIG_LOGIC_PIO. Reason is that CONFIG_PCI
>   depends on this, and CONFIG_PCI is a per-arch CONFIG.
>   So we would require all arch's kconfig to select this.
> - Addressed Dann Frazier's comments on LPC driver, and
>   sopme other cleanup
> - Moved logic_pio.h to be included in generic asm io.h
> - Fixed ACPI indirect IO host setup to handle >1 child
> - Relocated ACPI indirect IO host setup code to
>   drivers/acpi
> - Rebased to linux next-20180118
>
> Changes from v9:
>   - patch 2 has been split into 3 patches according to Bjorn comments on
> v9 thread
>   - patch 1 has been reworked accordign to Bjorn comments on v9
>   - now logic_pio_trans_hwaddr() has a sanity check to make sure the resource
> size fits into the assigned range
>   - in patch 5 the MFD framework has been used to probe the LPC children
> according to the suggestion from Mika Westerberg
>   - Maintaner has changed to Huawei Linuxarm mailing list
>
> Changes from v8:
>   - Simplified LIB IO framewrok
>   - Moved INDIRECT PIO ACPI framework under acpi/arm64
>   - Renamed occurrences of "lib io" and "indirect io" to "lib pio" and
> "indirect pio" to keep the patchset nomenclature consistent
>   - Removed Alignment reuqirements
>   - Moved LPC specific code out of ACPI common framework
>   - Now PIO indirect HW ranges can overlap
>   - Changed HiSilicon LPC driver maintainer (Gabriele Paoloni now) and split
> maintaner file modifications in a separate commit
>   - Removed the commit with the DT nodes support for hip06 and hip07 (to be
> pushed separately)
>   - Added a checking on ioport_map() not to break that function as Arnd points
> out in V7 review thread;
>   - fixed the compile issues on alpha, m68k;
>
> Changes from V7:
>   - Based on Arnd's comment, rename the LIBIO as LOGIC_PIO;
>   - Improved the mapping process in LOGIC_PIO to gain better efficiency when
> redirecting the I/O accesses to right device driver;
>   - To reduce the impact on PCI MMIO to a minimum, add a new
> CONFIG_INDIRECT_PIO for indirect-IO hosts/devices;
>   - Added a new ACPI handler for indirect-IO hosts/devices;
>   - Fixed the compile issues on V6;
>
> Changes from V6:
>   - According to the comments from Bjorn

Re: [PATCH v12 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

[dann frazier]

On Wed, Jan 24, 2018 at 12:36:22AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
> I/O port addresses. This patch implements the LPC host controller driver
> which perform the I/O operations on the underlying hardware.
> We don't want to touch those existing peripherals' driver, such as ipmi-bt.
> So this driver applies the indirect-IO introduced in the previous patch
> after registering an indirect-IO node to the indirect-IO devices list which
> will be searched in the I/O accessors to retrieve the host-local I/O port.
> 
> The driver config is set as a bool instead of a trisate. The reason
> here is that, by the very nature of the driver providing a logical
> PIO range, it does not make sense to have this driver as a loadable
> module. Another more specific reason is that the Huawei D03 board
> which includes hip06 SoC requires the LPC bus for UART console, so
> should be built in.
> 
> Signed-off-by: Zou Rongrong 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Rob Herring  #dts part
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  drivers/bus/Kconfig|   8 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 526 
> +
>  4 files changed, 568 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..213181f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,33 @@
> +Hisilicon Hip06 low-pin-count device
> +  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> +  provides I/O access to some legacy ISA devices.
> +  Hip06 is based on arm64 architecture where there is no I/O space. So, the
> +  I/O ports here are not cpu addresses, and there is no 'ranges' property in
> +  LPC device node.
> +
> +Required properties:
> +- compatible:  value should be as follows:
> + (a) "hisilicon,hip06-lpc"
> + (b) "hisilicon,hip07-lpc"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the LPC register set is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicon,hip06-lpc";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + };
> +};
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 57e011d..91debe4 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -65,6 +65,14 @@ config BRCMSTB_GISB_ARB
> arbiter. This driver provides timeout and target abort error handling
> and internal bus master decoding.
>  
> +config HISILICON_LPC
> + bool "Support for ISA I/O space on Hisilicon hip06/7"
> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST))
> + select INDIRECT_PIO
> + help
> +   Driver needed for some legacy ISA devices attached to Low-Pin-Count
> +   on Hisilicon hip06/7 SoC.
> +
>  config IMX_WEIM
>   bool "Freescale EIM DRIVER"
>   depends on ARCH_MXC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index 9bcd0bf..abc7a42 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
>  obj-$(CONFIG_ARM_CCN)+= arm-ccn.o
>  
>  obj-$(CONFIG_BRCMSTB_GISB_ARB)   += brcmstb_gisb.o
> +obj-$(CONFIG_HISILICON_LPC)  += hisi_lpc.o
>  obj-$(CONFIG_IMX_WEIM)   += imx-weim.o
>  obj-$(CONFIG_MIPS_CDMM)  += mips_cdmm.o
>  obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> new file mode 100644
> index 000..4ce089a
> --- /dev/null
> +++ b/drivers/bus/hisi_lpc.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + * Author: Zou Rongrong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the 

Re: [PATCH v13 1/9] LIB: Introduce a generic PIO mapping method

[dann frazier]

On Wed, Feb 14, 2018 at 01:45:25AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and
> pci_pio_to_address()"), a new I/O space management was supported. With
> that driver, the I/O ranges configured for PCI/PCIe hosts on some
> architectures can be mapped to logical PIO, converted easily between
> CPU address and the corresponding logicial PIO. Based on this, PCI
> I/O devices can be accessed in a memory read/write way through the
> unified in/out accessors.
> 
> But on some archs/platforms, there are bus hosts which access I/O
> peripherals with host-local I/O port addresses rather than memory
> addresses after memory-mapped.
> 
> To support those devices, a more generic I/O mapping method is introduced
> here. Through this patch, both the CPU addresses and the host-local port
> can be mapped into the logical PIO space with different logical/fake PIOs.
> After this, all the I/O accesses to either PCI MMIO devices or host-local
> I/O peripherals can be unified into the existing I/O accessors defined in
> asm-generic/io.h and be redirected to the right device-specific hooks
> based on the input logical PIO.
> 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: John Garry 
> ---
>  include/asm-generic/io.h  |   2 +
>  include/linux/logic_pio.h | 131 ++
>  lib/Kconfig   |  15 +++
>  lib/Makefile  |   2 +
>  lib/logic_pio.c   | 272 
> ++
>  5 files changed, 422 insertions(+)
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index b4531e3..b7996a79 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -351,6 +351,8 @@ static inline void writesq(volatile void __iomem *addr, 
> const void *buffer,
>  #define IO_SPACE_LIMIT 0x
>  #endif
>  
> +#include 
> +
>  /*
>   * {in,out}{b,w,l}() access little endian I/O. {in,out}{b,w,l}_p() can be
>   * implemented on hardware that needs an additional delay for I/O accesses to
> diff --git a/include/linux/logic_pio.h b/include/linux/logic_pio.h
> new file mode 100644
> index 000..b3322fd
> --- /dev/null
> +++ b/include/linux/logic_pio.h
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Gabriele Paoloni 
> + * Author: Zhichang Yuan 
> + *
> + */
> +
> +#ifndef __LINUX_LOGIC_PIO_H__
> +#define __LINUX_LOGIC_PIO_H__
> +
> +#ifdef __KERNEL__
> +
> +#include 
> +
> +#define PIO_INDIRECT 0x01UL /* indirect IO flag */
> +#define PIO_CPU_MMIO 0x00UL /* memory mapped io flag */
> +
> +struct logic_pio_hwaddr {
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + resource_size_t hw_start;
> + resource_size_t io_start;
> + resource_size_t size; /* range size populated */
> + unsigned long flags;
> +
> + void *devpara;  /* private parameter of the host device */
> + struct hostio_ops *ops; /* ops operating on this node */
> +};
> +
> +struct hostio_ops {
> + u32 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
> + size_t dlen);
> + u32 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
> + size_t dlen, unsigned int count);
> + void (*pfouts)(void *devobj, unsigned long ptaddr,
> + const void *outbuf, size_t dlen, unsigned int count);
> +};
> +
> +#ifdef CONFIG_INDIRECT_PIO
> +u8 logic_inb(unsigned long addr);
> +void logic_outb(u8 value, unsigned long addr);
> +void logic_outw(u16 value, unsigned long addr);
> +void logic_outl(u32 value, unsigned long addr);
> +u16 logic_inw(unsigned long addr);
> +u32 logic_inl(unsigned long addr);
> +void logic_outb(u8 value, unsigned long addr);
> +void logic_outw(u16 value, unsigned long addr);
> +void logic_outl(u32 value, unsigned long addr);
> +void logic_insb(unsigned long addr, void *buffer, unsigned int count);
> +void logic_insl(unsigned long addr, void *buffer, unsigned int count);
> +void logic_insw(unsigned long addr, void *buffer, unsigned int count);
> +void logic_outsb(unsigned long addr, const void *buffer, unsigned int count);
> +void logic_outsw(unsigned long addr, const void *buffer, unsigned int count);
> +void logic_outsl(unsigned long addr, const void *buffer, unsigned int count);
> +
> +#ifndef inb
> +#define inb logic_inb
> +#endif
> +
> +#ifndef inw
> +#define inw logic_inw
> +#endif
> +
> +#ifndef inl
> +#define inl logic_inl
> +#endif
> +
> +#ifndef outb
> +#define outb logic_outb
> +#endif
> +
> +#ifndef outw
> +#define 

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> After introducing the new generic I/O space management in logic pio, the
> original PCI MMIO relevant helpers need to be updated based on the new
> interfaces.
> This patch adapts the corresponding code to match the changes introduced
> by logic pio.
> 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann #earlier draft
> Acked-by: Bjorn Helgaas 

I saw that Bjorn Acked this back in v6, but it seems like the code in
pci.c was reworked a bit for v7 onwards and I didn't see a follow-up
review (apologies if I just missed it). In which case, maybe his Ack
should have the "#earlier draft" tag as well?

> ---
>  drivers/pci/pci.c| 95 
> +---
>  include/asm-generic/io.h |  2 +-
>  2 files changed, 18 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 07290a3..8aa5c54 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3440,17 +3441,6 @@ int pci_request_regions_exclusive(struct pci_dev 
> *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>  
> -#ifdef PCI_IOBASE
> -struct io_range {
> - struct list_head list;
> - phys_addr_t start;
> - resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
>  /*
>   * Record the PCI IO range (expressed as CPU physical address + size).
>   * Return a negative value if an error has occured, zero otherwise
> @@ -3458,51 +3448,28 @@ struct io_range {
>  int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
>   resource_size_t size)
>  {
> - int err = 0;
> -
> + int ret = 0;
>  #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - /* check if the range hasn't been previously recorded */
> - spin_lock(_range_lock);
> - list_for_each_entry(range, _range_list, list) {
> - if (addr >= range->start && addr + size <= range->start + size) 
> {
> - /* range already registered, bail out */
> - goto end_register;
> - }
> - allocated_size += range->size;
> - }
> + struct logic_pio_hwaddr *range;
>  
> - /* range not registed yet, check for available space */
> - if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> - /* if it's too big check if 64K space can be reserved */
> - if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> - err = -E2BIG;
> - goto end_register;
> - }
> -
> - size = SZ_64K;
> - pr_warn("Requested IO range too big, new size set to 64K\n");
> - }
> + if (!size || addr + size < addr)
> + return -EINVAL;
>  
> - /* add the range to the list */
>   range = kzalloc(sizeof(*range), GFP_ATOMIC);
> - if (!range) {
> - err = -ENOMEM;
> - goto end_register;
> - }
> + if (!range)
> + return -ENOMEM;
>  
> - range->start = addr;
> + range->fwnode = fwnode;
>   range->size = size;
> + range->hw_start = addr;
> + range->flags = PIO_CPU_MMIO;
>  
> - list_add_tail(>list, _range_list);
> -
> -end_register:
> - spin_unlock(_range_lock);
> + ret = logic_pio_register_range(range);
> + if (ret)
> + kfree(range);
>  #endif
>  
> - return err;
> + return ret;
>  }
>  
>  phys_addr_t pci_pio_to_address(unsigned long pio)
> @@ -3510,21 +3477,10 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>   phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
>  
>  #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - if (pio > IO_SPACE_LIMIT)
> + if (pio >= MMIO_UPPER_LIMIT)
>   return address;
>  
> - spin_lock(_range_lock);
> - list_for_each_entry(range, _range_list, list) {
> - if (pio >= allocated_size && pio < allocated_size + 
> range->size) {
> - address = range->start + pio - allocated_size;
> - break;
> - }
> - allocated_size += range->size;
> - }
> - spin_unlock(_range_lock);
> + address = logic_pio_to_hwaddr(pio);
>  #endif
>  
>   return address;
> @@ -3533,25 +3489,8 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
>  #ifdef PCI_IOBASE
> - struct io_range *res;
> - resource_size_t offset = 0;
> - unsigned long addr = -1;
> -
> - 

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Wed, Feb 14, 2018 at 8:42 AM, John Garry <john.ga...@huawei.com> wrote:
> On 13/02/2018 22:57, dann frazier wrote:
>>
>> On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote:
>>>
>>> From: Zhichang Yuan <yuanzhich...@hisilicon.com>
>>>
>>> After introducing the new generic I/O space management in logic pio, the
>>> original PCI MMIO relevant helpers need to be updated based on the new
>>> interfaces.
>>> This patch adapts the corresponding code to match the changes introduced
>>> by logic pio.
>>>
>>> Signed-off-by: Zhichang Yuan <yuanzhich...@hisilicon.com>
>>> Signed-off-by: Gabriele Paoloni <gabriele.paol...@huawei.com>
>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>#earlier draft
>>> Acked-by: Bjorn Helgaas <bhelg...@google.com>
>>
>>
>> I saw that Bjorn Acked this back in v6, but it seems like the code in
>> pci.c was reworked a bit for v7 onwards and I didn't see a follow-up
>> review (apologies if I just missed it). In which case, maybe his Ack
>> should have the "#earlier draft" tag as well?
>>
>
> Hi Dann,
>
> I see Bjorn acked again later on in the series, here:
> https://lkml.org/lkml/2017/5/26/612

Yep, you're right, sorry for missing that :)

>
>>> ---
>>>  drivers/pci/pci.c| 95
>>> +---
>>>  include/asm-generic/io.h |  2 +-
>>>  2 files changed, 18 insertions(+), 79 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 07290a3..8aa5c54 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -22,6 +22,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -3440,17 +3441,6 @@ int pci_request_regions_exclusive(struct pci_dev
>>> *pdev, const char *res_name)
>>>  }
>>>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>>>
>>> -#ifdef PCI_IOBASE
>>> -struct io_range {
>>> -   struct list_head list;
>>> -   phys_addr_t start;
>>> -   resource_size_t size;
>>> -};
>>> -
>>> -static LIST_HEAD(io_range_list);
>>> -static DEFINE_SPINLOCK(io_range_lock);
>>> -#endif
>>> -
>>>  /*
>>>   * Record the PCI IO range (expressed as CPU physical address + size).
>>>   * Return a negative value if an error has occured, zero otherwise
>>> @@ -3458,51 +3448,28 @@ struct io_range {
>>>  int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t
>>> addr,
>>> resource_size_t size)
>>>  {
>>> -   int err = 0;
>>> -
>>> +   int ret = 0;
>>>  #ifdef PCI_IOBASE
>>> -   struct io_range *range;
>>> -   resource_size_t allocated_size = 0;
>>> -
>>> -   /* check if the range hasn't been previously recorded */
>>> -   spin_lock(_range_lock);
>>> -   list_for_each_entry(range, _range_list, list) {
>>> -   if (addr >= range->start && addr + size <= range->start +
>>> size) {
>>> -   /* range already registered, bail out */
>>> -   goto end_register;
>>> -   }
>>> -   allocated_size += range->size;
>>> -   }
>>> +   struct logic_pio_hwaddr *range;
>>>
>>> -   /* range not registed yet, check for available space */
>>> -   if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
>>> -   /* if it's too big check if 64K space can be reserved */
>>> -   if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
>>> -   err = -E2BIG;
>>> -   goto end_register;
>>> -   }
>>> -
>>> -   size = SZ_64K;
>>> -   pr_warn("Requested IO range too big, new size set to
>>> 64K\n");
>>> -   }
>>> +   if (!size || addr + size < addr)
>>> +   return -EINVAL;
>>>
>>> -   /* add the range to the list */
>>> range = kzalloc(sizeof(*range), GFP_ATOMIC);
>>> -   if (!range) {
>>> -   err = -ENOMEM;
>>> -   goto end_register;
>>> -   }
>>> +   if (!range)
>>

Re: [PATCH v14 0/9] LPC: legacy ISA I/O support

[dann frazier]

  MAINTAINERS|   7 +
>  drivers/acpi/pci_root.c|   8 +-
>  drivers/acpi/scan.c|  14 +
>  drivers/bus/Kconfig|   8 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 646 
> +
>  drivers/of/address.c   |  96 ++-
>  drivers/pci/pci.c  |  95 +--
>  include/asm-generic/io.h   |   4 +-
>  include/linux/logic_pio.h  | 131 +
>  include/linux/pci.h|   3 +-
>  lib/Kconfig|  15 +
>  lib/Makefile   |   2 +
>  lib/logic_pio.c| 285 +
>  15 files changed, 1250 insertions(+), 98 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c

Tested this version on a D05 board, no problems. So, for the series:

Tested-by: dann frazier <dann.fraz...@canonical.com>

Re: [PATCH 1/4] i2c: xlp9xx: return ENXIO on slave address NACK

[dann frazier]

On Tue, Jan 30, 2018 at 7:28 AM, George Cherian
<gcher...@caviumnetworks.com> wrote:
> Gentle Ping on this series.

I've been using these on a few Cavium Sabre boards, which previously
had an unusable system interface (/dev/ipmi) due to timeouts or just
enumerations failures. So, fwiw:

Tested-by: dann frazier <dann.fraz...@canonical.com>

 -dann

> On 01/18/2018 11:09 AM, George Cherian wrote:
>>
>> From: Dmitry Bazhenov <dmitry.bazhe...@auriga.com>
>>
>> Fix the driver violation of the common practice to return
>> ENXIO error on a slave address NACK.
>>
>> Signed-off-by: Dmitry Bazhenov <dmitry.bazhe...@auriga.com>
>> Signed-off-by: George Cherian <george.cher...@cavium.com>
>> ---
>>   drivers/i2c/busses/i2c-xlp9xx.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-xlp9xx.c
>> b/drivers/i2c/busses/i2c-xlp9xx.c
>> index b970bf8..6d78cdc 100644
>> --- a/drivers/i2c/busses/i2c-xlp9xx.c
>> +++ b/drivers/i2c/busses/i2c-xlp9xx.c
>> @@ -324,7 +324,8 @@ static int xlp9xx_i2c_xfer_msg(struct xlp9xx_i2c_dev
>> *priv, struct i2c_msg *msg,
>> dev_dbg(priv->dev, "transfer error %x!\n", priv->msg_err);
>> if (priv->msg_err & XLP9XX_I2C_INTEN_BUSERR)
>> xlp9xx_i2c_init(priv);
>> -   return -EIO;
>> +   return (priv->msg_err & XLP9XX_I2C_INTEN_NACKADDR) ?
>> +   -ENXIO : -EIO;
>> }
>> if (timeleft == 0) {
>>
>
> Regards
> -George

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Sat, Jul 14, 2018 at 5:21 AM dann frazier  wrote:
>
> On Thu, Jul 12, 2018 at 5:08 PM Theodore Y. Ts'o  wrote:
> >
> > >
> > > Review console log and on each run I have filesystem rebuild. The problem
> > > is that mke2fs I am using is 1.44.3-rc2. I am now reseting the environment
> > > and re-test.
> > >
> >
> > Could it be that you saw the error in ext4_validate_block_bitmap()?
>
> Looks like it. From Ike's report:
>
> # grep EXT4 d05-4-ipmi.log
> [ 26.215587] EXT4-fs (sdb2): mounted filesystem with ordered data
> mode. Opts: (null)
> [ 29.844105] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
> [ 3586.211348] EXT4-fs error (device sda2):
> ext4_validate_block_bitmap:383: comm stress-ng: bg 4705: bad block
> bitmap checksum
> [ 8254.776992] EXT4-fs error (device sda2):
> ext4_validate_block_bitmap:383: comm stress-ng: bg 4193: bad block
> bitmap checksum
>
> I've ran my test case for several days w/ just the inode bitmap fix
> and haven't been able to reproduce it - but perhaps that's just the
> nature of the chdir test.

hey Ted,

Turns out the stress-ng 'mknod' test and - less reliably - the
'dentry' test can tickle the "bad block bitmap checksum" bug pretty
easily. stress-ng wasn't *detecting* the error, but Colin has just
released a new version that does. We've been running with your updated
patch on 3 machines for several iterations, and have not seen another
occurrence.

  -dann

> > The patch which I sent Dann only fixed the problem for inode bitmaps;
> > I noticed today that we need to fix it for block allocation bitmaps as
> > well.
>
> I've also now ran several iterations w/ the block bitmap fix as well,
> and still no problems, so:
>
> Tested-by: dann frazier 
>
> > commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef
> > Author: Theodore Ts'o 
> > Date:   Thu Jul 12 19:08:05 2018 -0400
> >
> > ext4: check for allocation block validity with block group locked
> >
> > With commit 044e6e3d74a3: "ext4: don't update checksum of new
> > initialized bitmaps" the buffer valid bit will get set without
> > actually setting up the checksum for the allocation bitmap, since the
> > checksum will get calculated once we actually allocate an inode or
> > block.
> >
> > If we are doing this, then we need to (re-)check the verified bit
> > after we take the block group lock.  Otherwise, we could race with
> > another process reading and verifying the bitmap, which would then
> > complain about the checksum being invalid.
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137
> >
> > Signed-off-by: Theodore Ts'o 
> > Cc: sta...@kernel.org
>
> Would it also make sense to add the following?
>
> Fixes: 044e6e3d74a3 ("ext4: don't update checksum of new initialized bitmaps")
>
>   -dann
>
> > diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> > index e68cefe08261..aa52d87985aa 100644
> > --- a/fs/ext4/balloc.c
> > +++ b/fs/ext4/balloc.c
> > @@ -368,6 +368,8 @@ static int ext4_validate_block_bitmap(struct 
> > super_block *sb,
> > return -EFSCORRUPTED;
> >
> > ext4_lock_group(sb, block_group);
> > +   if (buffer_verified(bh))
> > +   goto verified;
> > if (unlikely(!ext4_block_bitmap_csum_verify(sb, block_group,
> > desc, bh))) {
> > ext4_unlock_group(sb, block_group);
> > @@ -386,6 +388,7 @@ static int ext4_validate_block_bitmap(struct 
> > super_block *sb,
> > return -EFSCORRUPTED;
> > }
> > set_buffer_verified(bh);
> > +verified:
> > ext4_unlock_group(sb, block_group);
> > return 0;
> >  }
> > diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> > index fb83750c1a14..e9d8e2667ab5 100644
> > --- a/fs/ext4/ialloc.c
> > +++ b/fs/ext4/ialloc.c
> > @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> > *sb,
> > return -EFSCORRUPTED;
> >
> > ext4_lock_group(sb, block_group);
> > +   if (buffer_verified(bh))
> > +   goto verified;
> > blk = ext4_inode_bitmap(sb, desc);
> > if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
> >EXT4_INODES_PER_GROUP(sb) / 8)) {
> > @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct 
> > super_block *sb,
> > return -EFSBADCRC;
> > }
> > set_buffer_verified(bh);
> > +verified:
> > ext4_unlock_group(sb, block_group);
> > return 0;
> >  }

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Thu, Jul 12, 2018 at 5:08 PM Theodore Y. Ts'o  wrote:
>
> >
> > Review console log and on each run I have filesystem rebuild. The problem
> > is that mke2fs I am using is 1.44.3-rc2. I am now reseting the environment
> > and re-test.
> >
>
> Could it be that you saw the error in ext4_validate_block_bitmap()?

Looks like it. From Ike's report:

# grep EXT4 d05-4-ipmi.log
[ 26.215587] EXT4-fs (sdb2): mounted filesystem with ordered data
mode. Opts: (null)
[ 29.844105] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
[ 3586.211348] EXT4-fs error (device sda2):
ext4_validate_block_bitmap:383: comm stress-ng: bg 4705: bad block
bitmap checksum
[ 8254.776992] EXT4-fs error (device sda2):
ext4_validate_block_bitmap:383: comm stress-ng: bg 4193: bad block
bitmap checksum

I've ran my test case for several days w/ just the inode bitmap fix
and haven't been able to reproduce it - but perhaps that's just the
nature of the chdir test.

> The patch which I sent Dann only fixed the problem for inode bitmaps;
> I noticed today that we need to fix it for block allocation bitmaps as
> well.

I've also now ran several iterations w/ the block bitmap fix as well,
and still no problems, so:

Tested-by: dann frazier 

> commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef
> Author: Theodore Ts'o 
> Date:   Thu Jul 12 19:08:05 2018 -0400
>
> ext4: check for allocation block validity with block group locked
>
> With commit 044e6e3d74a3: "ext4: don't update checksum of new
> initialized bitmaps" the buffer valid bit will get set without
> actually setting up the checksum for the allocation bitmap, since the
> checksum will get calculated once we actually allocate an inode or
> block.
>
> If we are doing this, then we need to (re-)check the verified bit
> after we take the block group lock.  Otherwise, we could race with
> another process reading and verifying the bitmap, which would then
> complain about the checksum being invalid.
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137
>
> Signed-off-by: Theodore Ts'o 
> Cc: sta...@kernel.org

Would it also make sense to add the following?

Fixes: 044e6e3d74a3 ("ext4: don't update checksum of new initialized bitmaps")

  -dann

> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index e68cefe08261..aa52d87985aa 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -368,6 +368,8 @@ static int ext4_validate_block_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
>
> ext4_lock_group(sb, block_group);
> +   if (buffer_verified(bh))
> +   goto verified;
> if (unlikely(!ext4_block_bitmap_csum_verify(sb, block_group,
> desc, bh))) {
> ext4_unlock_group(sb, block_group);
> @@ -386,6 +388,7 @@ static int ext4_validate_block_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
> }
> set_buffer_verified(bh);
> +verified:
> ext4_unlock_group(sb, block_group);
> return 0;
>  }
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index fb83750c1a14..e9d8e2667ab5 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
> return -EFSCORRUPTED;
>
> ext4_lock_group(sb, block_group);
> +   if (buffer_verified(bh))
> +   goto verified;
> blk = ext4_inode_bitmap(sb, desc);
> if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
>EXT4_INODES_PER_GROUP(sb) / 8)) {
> @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
> return -EFSBADCRC;
> }
> set_buffer_verified(bh);
> +verified:
> ext4_unlock_group(sb, block_group);
> return 0;
>  }

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote:
> > Hi,
> >   We're seeing a regression triggered by the stress-ng[*] "chdir" test
> > that I've bisected to:
> > 
> > 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps
> > 
> > So far we've only seen failures on servers based on HiSilicon's family
> > of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
> > very reproducible.
> 
> Thanks for the report.  Can you verify whether or not this patch fixes
> things for you?

hey Ted,
  Sorry for the delayed response - was afk for a long weekend.
Your patch does seem to fix the issue for me - after applying the
patch, I was able to survive 20 iterations (and counting), where
previously it would always fail the first time.

However, I've received a conflicting report from a colleague who
appears to still be seeing errors. I'll get back to you ASAP once I am
able to (in-?)validate that observation.

  -dann

>   - Ted
> 
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index da6c10c1e37a..1cfb74bc4dca 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -90,6 +90,8 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
>   return -EFSCORRUPTED;
>  
>   ext4_lock_group(sb, block_group);
> + if (buffer_verified(bh))
> + goto verified;
>   blk = ext4_inode_bitmap(sb, desc);
>   if (!ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh,
>  EXT4_INODES_PER_GROUP(sb) / 8)) {
> @@ -101,6 +103,7 @@ static int ext4_validate_inode_bitmap(struct super_block 
> *sb,
>   return -EFSBADCRC;
>   }
>   set_buffer_verified(bh);
> +verified:
>   ext4_unlock_group(sb, block_group);
>   return 0;
>  }

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

On Tue, Jul 10, 2018 at 10:51:43AM -0600, dann frazier wrote:
> On Sat, Jul 07, 2018 at 12:10:18AM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote:
> > > Hi,
> > >   We're seeing a regression triggered by the stress-ng[*] "chdir" test
> > > that I've bisected to:
> > > 
> > > 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps
> > > 
> > > So far we've only seen failures on servers based on HiSilicon's family
> > > of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
> > > very reproducible.
> > 
> > Thanks for the report.  Can you verify whether or not this patch fixes
> > things for you?
> 
> hey Ted,
>   Sorry for the delayed response - was afk for a long weekend.
> Your patch does seem to fix the issue for me - after applying the
> patch, I was able to survive 20 iterations (and counting), where
> previously it would always fail the first time.
> 
> However, I've received a conflicting report from a colleague who
> appears to still be seeing errors. I'll get back to you ASAP once I am
> able to (in-?)validate that observation.

OK - I believe I found an explanation for my colleague's continued
test failures after applying the patch. The filesystem being used may
have already been corrupted from a previous run, and the test w/ your
patch just tripped over it. Details are here starting in comment #9 if
you'd like to look them over:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137

  -dann

[Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

[dann frazier]

Hi,
  We're seeing a regression triggered by the stress-ng[*] "chdir" test
that I've bisected to:

044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps

So far we've only seen failures on servers based on HiSilicon's family
of ARM64 SoCs (D05/Hi1616 SoC, D06/Hi1620 SoC). On these systems it is
very reproducible.

= Test Case =
#!/bin/sh
umount /tmp/mnt || /bin/true
mkdir -p /tmp/mnt
mkfs.ext4 -F /dev/sda1
mount /dev/sda1 /tmp/mnt
# Running directly under /tmp/mnt doesn't trigger the issue, we need
# this subdirectory for some reason
dir="/tmp/mnt/tmp/disk_stress_ng_f70f0f26-b332-4c48-9e07-67c529770e3d"
mkdir -p "$dir"
stress-ng --aggressive --verify --timeout 240 --temp-path "$dir" \
  --chdir 0 --hdd-opts dsync --readahead-bytes 16M -k

= Result =
[70586.263840] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[70586.637085] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 43936, inode_bitmap = 1439694864
[70602.296551] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 48896, inode_bitmap = 1602224144
[70602.409291] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:98: comm 
stress-ng: Corrupt inode bitmap - block_group = 48928, inode_bitmap = 1603272720

Full dmesg:
  
http://people.canonical.com/~dannf/d05-stress-ng/d05-sas-chdir-4.18.0-rc3+.dmesg

[*] http://kernel.ubuntu.com/~cking/stress-ng/

[PATCH] net: hns: Avoid action name truncation

[dann frazier]

When longer interface names are used, the action names exposed in
/proc/interrupts and /proc/irq/* maybe truncated. For example, when
using the predictable name algorithm in systemd on a HiSilicon D05,
I see:

  ubuntu@d05-3:~$  grep enahisic2i0-tx /proc/interrupts | sed 's/.* //'
  enahisic2i0-tx0
  enahisic2i0-tx1
  [...]
  enahisic2i0-tx8
  enahisic2i0-tx9
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1

Increase the max ring name length to allow for an interface name
of IFNAMSIZE. After this change, I now see:

  $ grep enahisic2i0-tx /proc/interrupts | sed 's/.* //'
  enahisic2i0-tx0
  enahisic2i0-tx1
  enahisic2i0-tx2
  [...]
  enahisic2i0-tx8
  enahisic2i0-tx9
  enahisic2i0-tx10
  enahisic2i0-tx11
  enahisic2i0-tx12
  enahisic2i0-tx13
  enahisic2i0-tx14
  enahisic2i0-tx15

Signed-off-by: dann frazier <dann.fraz...@canonical.com>
---
 drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index 3e62692af011..fa5b30f547f6 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -87,7 +87,7 @@ do { \
 
 #define HNAE_AE_REGISTER 0x1
 
-#define RCB_RING_NAME_LEN 16
+#define RCB_RING_NAME_LEN (IFNAMSIZ + 4)
 
 #define HNAE_LOWEST_LATENCY_COAL_PARAM 30
 #define HNAE_LOW_LATENCY_COAL_PARAM80
-- 
2.17.0

udev/aacraid interaction - should aacraid set 'removable'?

[dann frazier]

(lkml readers: this concerns a security issue reported to debian by a
user of udev/aacraid. udev gives the aacraid devices the floppy group
because it reports block devices as 'removable'. See
http://bugs.debian.org/404927 for the entire thread).

On Wed, Jan 03, 2007 at 11:49:51AM +0100, Marco d'Itri wrote:
> On Jan 03, dann frazier <[EMAIL PROTECTED]> wrote:
> 
> >  Can you elaborate on what you believe the kernel is doing
> > incorrectly? My first guess would be the setting of the removable
> > flag, but aacraid claims to be setting this to prevent partition table
> > caching - do you believe that to be an incorrect usage?
> Yes, this looks like an abuse of the interface to me.

Ok, let's ask lkml

> > It seems like there is precedence for workarounds for older kernels in
> > permissions.rules, so would it be appropriate to add an override of
> > the default floppy rule for aacraid devices for compatability even if
> > this is a kernel bug?
> There are workarounds for bugs which are going to be fixed, but looks
> like this is going to stay forever...
> Are there other drivers in this situation?

I didn't turn up any otherwise when I was grepping yesterday, but my
search terms may have been too naive. I also checked a machine I had
w/ cciss - it did not have the removable flag set.

I found a message from Mark Salyzyn from last year that suggested this
was more pervasive:
  http://www.ussg.iu.edu/hypermail/linux/kernel/0602.2/1231.html
Mark: Can you identify some of these other drivers?


-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: udev/aacraid interaction - should aacraid set 'removable'?

[dann frazier]

On Wed, Jan 03, 2007 at 12:17:47PM -0500, Salyzyn, Mark wrote:
> The ips driver, indirectly via Firmware as it spoofs it's own inquiry
> data, reports the Removable bit set in the inquiry response for the
> arrays. The dpt_i2o driver similarly has the firmware constructing the
> bit set. Some of the Array Bridges and external RAID boxes do the same
> thing.

Thanks Mark. If you have any of these devices, could you help supply
the udevinfo information? Our udev maintainer has asked for this so
that he can workaround this issue by special casing these
devices. (See http://bugs.debian.org/404927 for details).

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19-git20 cciss: cmd f7b00000 timedout

[dann frazier]

On Thu, Dec 14, 2006 at 01:44:34PM -0600, Miller, Mike (OS Dev) wrote:
>  
> 
> > -Original Message-
> > From: Jens Axboe [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, December 14, 2006 12:51 PM
> > To: Steve Roemen
> > Cc: LKML; ISS StorageDev; Miller, Mike (OS Dev)
> > Subject: Re: 2.6.19-git20 cciss: cmd f7b0 timedout
> > 
> > On Thu, Dec 14 2006, Steve Roemen wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > > 
> > > All,
> > > I tried out the 2.6.19-git20 kernel on one of my machines (HP 
> > > DL380 G3) that has the on board 5i controller (disabled),
> > > 2 smart array 642 controllers.
> > > 
> > > I get the error (cciss: cmd f7b0 timedout) with Buffer 
> > I/O error 
> > > on device cciss/c (all cards, and disks) logical block 0, 1, 2, etc
> > 
> > I saw this on another box, but it works on the ones that I have. Does
> > 2.6.19 work? Any chance you can try and narrow down when it broke?
> 
> Jens/Steve:
> We also encountered a time out issue on the 642. This one is connected
> to an MSA500. Do either of you have MSA500? What controller fw are you
> running? Check /proc/driver/cciss/ccissN.

fyi, we've been seeing this in Debian too (which is why Mike added me
to the CC list), and I've narrowed it down to the 2TB patch that went
into 2.6.19:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402787
-- 
dann frazier | HP Open Source and Linux Organization
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19-git20 cciss: cmd f7b00000 timedout

[dann frazier]

On Thu, Dec 14, 2006 at 04:16:39PM -0600, Miller, Mike (OS Dev) wrote:
> H. Dann, did you see this on 32-bit Debian?

yep - all reports I've seen so far are on i386



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> Dann, do you still have your samba server ready to try to reproduce this
> problem ? Also, there are very suspect lines right there in the patch :

I can set it up again, hopefully have some feedback by tomorrow.

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> @@ -505,8 +510,13 @@
>   mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
>   mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
>  
> - mnt->flags = (oldmnt->file_mode >> 9);
> + mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
> + SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
>   } else {
> + mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> + S_IROTH | S_IXOTH | S_IFREG;
> + mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> + S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;
>   }
> 
> 
> See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
> expected thing like this but I wonder if the initial intent was
> exactly this.

Wow - sorry about that, that's certainly a cut & paste error. But the
end result appears to match current 2.6, which was the intent.

> Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
> what I say is stupid, but it's just a guess.

I really don't know the correct answer to that, I was merely copying
the 2.6 flags. 

[Still working on getting a 2.4 smbfs test system up...]

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/12] repost: cciss: add busy_configuring flag

[dann frazier]

On Wed, Dec 13, 2006 at 01:52:36PM +0100, Jens Axboe wrote:
> On Tue, Dec 12 2006, Mike Miller (OS Dev) wrote:
> > On Mon, Nov 06, 2006 at 09:32:00PM +0100, Jens Axboe wrote:
> > > On Mon, Nov 06 2006, Mike Miller (OS Dev) wrote:
> > > > PATCH 9 of 12
> > > > 
> > > > This patch adds a check for busy_configuring to prevent starting a queue
> > > > on a drive that may be in the midst of updating, configuring, deleting, 
> > > > etc.
> > > > 
> > > > This had a test for if the queue was stopped or plugged but that seemed
> > > > to cause issues.
> > > > Please consider this for inclusion.
> > > > 
> > > > Thanks,
> > > > mikem
> > > > 
> > > > Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
> > > > 
> > > > 
> > > > 
> > > > ---
> > > > 
> > > >  drivers/block/cciss.c |5 -
> > > >  1 files changed, 4 insertions(+), 1 deletion(-)
> > > > 
> > > > diff -puN drivers/block/cciss.c~cciss_busy_conf_for_lx2619-rc4 
> > > > drivers/block/cciss.c
> > > > --- linux-2.6/drivers/block/cciss.c~cciss_busy_conf_for_lx2619-rc4  
> > > > 2006-11-06 13:27:53.0 -0600
> > > > +++ linux-2.6-root/drivers/block/cciss.c2006-11-06 
> > > > 13:27:53.0 -0600
> > > > @@ -1190,8 +1190,11 @@ static void cciss_check_queues(ctlr_info
> > > > /* make sure the disk has been added and the drive is 
> > > > real
> > > >  * because this can be called from the middle of 
> > > > init_one.
> > > >  */
> > > > -   if (!(h->drv[curr_queue].queue) || 
> > > > !(h->drv[curr_queue].heads))
> > > > +   if (!(h->drv[curr_queue].queue) ||
> > > > +   !(h->drv[curr_queue].heads) ||
> > > > +   h->drv[curr_queue].busy_configuring)
> > > > continue;
> > > > +
> > > > blk_start_queue(h->gendisk[curr_queue]->queue);
> > > 
> > > This is racy, because you don't start the queue when you unset
> > > ->busy_configuring later on. For this to be safe, you need to call
> > > blk_start_queue() when you set ->busy_configuring to 0.
> > 
> > Jens, please see Chase's reply to your concerns:
> > > busy_configuring - I do not think this is racy.  This
> > > flag is used only when we are removing/deleting a disk.  In
> > > this case the queue is cleaned up and the disk is deleted.
> > > If we are doing that then there is no queue to start later.
> > > The check of this flag in the interrupt handler is to prevent
> > > us from trying to start a queue that is in the middle of
> > > being deleted.  This flag could be called busy_deleting.
> 
> Ok, no worries then if it's simply a going away flag. I wonder if it's
> needed at all, but it certainly doesn't hurt.

hey Jens,
  Just a poke since I haven't seen this change go into your block
tree. Is it still in-plan?

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
> On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> > @@ -505,8 +510,13 @@
> > mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
> > mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
> >  
> > -   mnt->flags = (oldmnt->file_mode >> 9);
> > +   mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
> > +   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
> > } else {
> > +   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > +   S_IROTH | S_IXOTH | S_IFREG;
> > +   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > +   S_IROTH | S_IXOTH | S_IFDIR;
> > if (parse_options(mnt, raw_data))
> > goto out_bad_option;
> > }
> > 
> > 
> > See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
> > expected thing like this but I wonder if the initial intent was
> > exactly this.
> 
> Wow - sorry about that, that's certainly a cut & paste error. But the
> end result appears to match current 2.6, which was the intent.
> 
> > Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
> > what I say is stupid, but it's just a guess.
> 
> I really don't know the correct answer to that, I was merely copying
> the 2.6 flags. 
> 
> [Still working on getting a 2.4 smbfs test system up...]

Ah, think I see the problem now:

--- kernel-source-2.4.27.orig/fs/smbfs/proc.c   2007-01-19 17:53:57.247695476 
-0700
+++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 
-0700
@@ -1997,7 +1997,7 @@
fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
  !(S_ISDIR(fattr->f_mode)) )
-   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | (fattr->f_mode & S_IFMT);
 
 }
 
Santiago: Thanks for reporting this - can you test this patch out on
your system and let me know if there are still any problems?

Willy: I'll do some more testing and get you a patch that fixes this
and the double assignment nonsense. Would you prefer a single patch or
two?

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Mon, Jan 22, 2007 at 10:50:47AM +1100, Grant Coady wrote:
> On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.4.34b
> [EMAIL PROTECTED]:/home/other$ mkdir test
> [EMAIL PROTECTED]:/home/other$ ln -s test testlink
> ln: creating symbolic link `testlink' to `test': Operation not permitted
> [EMAIL PROTECTED]:/home/other$ echo "this is also a test" > test/file
> [EMAIL PROTECTED]:/home/other$ ln -s test/file test2
> ln: creating symbolic link `test2' to `test/file': Operation not permitted
> 
> trying to create symlinks.
> 
> No problems creating symlinks with 2.4.33.3.

Yes, I've found that this varies depending upon the options passed. If
uid=0, I can create symlinks, otherwise I always get permission
denied. This behavior appears to be consistent with 2.6.

I also need to do some testing with the proposed patch to smbmount
that will let you omit options (current versions will always pass an
option to the kernel, even if you the user did not provide one).
If you do not pass options, the behavior should fallback to
server-provided values.

Note that this bug has been my only interaction with smbfs, so I'm
certainly no expert on how it *should* behave. My plan is to
take all of the use cases we're coming up with and try to maintain
the "historic" 2.4 behavior as much as possible, but still not
silently dropping user-provided mount options. When the behavior needs
to change to honor them, I'll try to match what current 2.6
does. Make sense?

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Mon, Jan 22, 2007 at 12:03:21AM +0100, Willy Tarreau wrote:
> Hi Grant !
> 
> On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
> > On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
> > 
> > >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
> > >Ah, think I see the problem now:
> > >
> > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 
> > >17:53:57.247695476 -0700
> > >+++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
> > >-0700
> > >@@ -1997,7 +1997,7 @@
> > >   fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
> > > S_IRWXO)) | S_IFDIR;
> > >   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> > > !(S_ISDIR(fattr->f_mode)) )
> > >-  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> > >S_IRWXO)) | S_IFREG;
> > >+  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> > >S_IRWXO)) | (fattr->f_mode & S_IFMT);
> > > 
> > > }
> > > 
> > client running 2.4.34 with above patch, server is running 2.6.19.2 to 
> > eliminate it from the problem space (hopefully ;) :
> > [EMAIL PROTECTED]:/home/other$ uname -r
> > 2.4.34b
> > [EMAIL PROTECTED]:/home/other$ ls -l
> > total 9
> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
> 
> It seems to me that there is a difference, because filelink now appears the
> same size as file. It's just as if we had hard links instead of symlinks.

I was running into this yesterday - turns out that Debian's current
smbfs package contains a patch that checks for user passed options,
and disables unix capabilities in that case. It was added in
3.0.14a-4. I've filed a bug requesting the removal of this patch:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408033

Grant: Do you know if are you running a version of smbfs w/ this
   patch?

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

Users have reported a symlink issue with my recent smbfs backport.
Turns out my backport overlooked a second 2.6 patch w/ the fix:
 
http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w

This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
issue, and also cleans up an unnecessary double assignment. As his
commit message notes, you will need the userspace patches from Samba
Bug #999 in order to use the permission/ownership assigned by the
server.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>

diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
index be975fe..7fd9b51 100644
--- a/fs/smbfs/inode.c
+++ b/fs/smbfs/inode.c
@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
int silent)
mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
} else {
-   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFREG;
-   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFDIR;
+   mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFREG;
+   mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFDIR;
if (parse_options(mnt, raw_data))
goto out_bad_option;
}
diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
index 7f0794c..5570007 100644
--- a/fs/smbfs/proc.c
+++ b/fs/smbfs/proc.c
@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
struct smb_sb_info *server,
 
if ( (server->mnt->flags & SMB_MOUNT_DMODE) &&
 (S_ISDIR(fattr->f_mode)) )
-   fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
+   fattr->f_mode = (server->mnt->dir_mode & S_IRWXUGO) | S_IFDIR;
else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
  !(S_ISDIR(fattr->f_mode)) )
-   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+   fattr->f_mode = (server->mnt->file_mode & S_IRWXUGO) |
+   (fattr->f_mode & S_IFMT);
 
 }
 


-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 24, 2007 at 08:04:36AM +1100, Grant Coady wrote:
> Hi Dann,
> I'm running slackware-11, no smbfs package, 'smbmnt' is from samba-3.0.23c 
> package with two tiny unrelated (?) patches:

Thanks again Grant. You might check out the patch I just submitted -
turns out this was an issue that was already fixed in 2.6, and that
fix is more complete than my previous one. You'll need the additional
userspace patches to use the server-provided perms (i.e., get rid of
the +x bits).

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 24, 2007 at 10:46:24AM +1100, Grant Coady wrote:
> On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
> 
> >Users have reported a symlink issue with my recent smbfs backport.
> >Turns out my backport overlooked a second 2.6 patch w/ the fix:
> > http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w
> >
> >This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
> >issue, and also cleans up an unnecessary double assignment. As his
> >commit message notes, you will need the userspace patches from Samba
> >Bug #999 in order to use the permission/ownership assigned by the
> >server.
> 
> Server-side:
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.6.19.2a
> [EMAIL PROTECTED]:/home/other$ ls -l
> total 8
> drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
> lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
> -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
> lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
> -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
> lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test
> 
> Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
> for comparison:
> 
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.4.33.3
> [EMAIL PROTECTED]:/home/other$ ls -l
> total 4096
> drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
> lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
> -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
> lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
> -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
> lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test
> 
> [EMAIL PROTECTED]:~$ uname -r
> 2.6.19.2a
> [EMAIL PROTECTED]:~$ ls -l /home/other/
> total 10
> drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
> lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
> lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
> -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
> lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*
> 
> [EMAIL PROTECTED]:~$ uname -r
> 2.4.34c
> [EMAIL PROTECTED]:~$ ls -l /home/other/
> total 4096
> drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
> lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
> lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
> -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
> lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

Great, that's what I'd expect. If you patch your userspace, you can
avoid the executable bits.


-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

old buffer overflow in moxa driver

[dann frazier]

hey,
  I noticed that the moxa input checking security bug described by
CVE-2005-0504 appears to remain unfixed upstream.
 
The issue is described here:
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504

Debian has been shipping the following patch from Andres Salomon. I
tried contacting the listed maintainer a few months ago but received
no response.

I've tested that this still applies to and compiles against 2.6.21.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>

diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index 7dbaee8..e0d35c2 100644
--- a/drivers/char/moxa.c
+++ b/drivers/char/moxa.c
@@ -1582,7 +1582,7 @@ copy:
 
if(copy_from_user(, argp, sizeof(struct dl_str)))
return -EFAULT;
-   if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS)
+   if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS || dltmp.len < 0)
return -EINVAL;
 
switch(cmd)
@@ -2529,6 +2529,8 @@ static int moxaloadbios(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr;
int i;
 
+   if(len < 0 || len > sizeof(moxaBuff))
+   return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
baseAddr = moxa_boards[cardno].basemem;
@@ -2576,7 +2578,7 @@ static int moxaload320b(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr;
int i;
 
-   if(len > sizeof(moxaBuff))
+   if(len < 0 || len > sizeof(moxaBuff))
return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
@@ -2596,6 +2598,8 @@ static int moxaloadcode(int cardno, unsigned char __user 
*tmp, int len)
void __iomem *baseAddr, *ofsAddr;
int retval, port, i;
 
+   if(len < 0 || len > sizeof(moxaBuff))
+   return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
baseAddr = moxa_boards[cardno].basemem;

-- 
dann frazier
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: old buffer overflow in moxa driver

[dann frazier]

On Tue, May 01, 2007 at 04:29:27AM -0400, Andres Salomon wrote:
> Right; the lack of input checking is most definitely a bug.  It's no
> longer a security issue, as a CAP_SYS_RAWIO check was added at some
> point to the code path, but it's still a bug.

I hadn't noticed this, but yes - the CAP_SYS_RAWIO check was added in
2.6.16.

-- 
dann frazier | HP Open Source and Linux Organization
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller

[Dann Frazier]

On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar  wrote:
> This patch adds support for AppliedMicro X-Gene PCIe host controller. The
> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
> cards.
>
> X-Gene PCIe controller driver has depedency on the pcie arch support for
> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
> and approach for arch support is under discussion with arm64 maintainers.
> The reference patch can be found here --> https://lkml.org/lkml/2013/10/23/244

The reference patch looks corrupted (pcibios.c has no includes, etc),
would you mind reposting?

  -dann

> If someone wishes to test PCIe on X-Gene, arch support patch must be applied
> before the patches in this patch set.
>
> changes since V2:
> 1. redefined each PCI port in different PCI domain correctly.
> 2. removed setup_lane and setup_link functions from driver.
> 3. removed scan_bus wrapper and set_primary_bus hack.
> 4. added pci_ioremap_io for io resources.
>
> changes since V1:
> 1. added PCI domain support
> 2. reading cpu and pci addresses from device tree to configure regions.
> 3. got rid of unnecessary wrappers for readl and writel.
> 4. got rid of endpoint configuration code.
> 5. added 'dma-ranges' property support to read inbound region configuration.
> 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
> 7. dropped 'clock-names' property from bindings
> 8. added comments whereever requested.
>
> Tanmay Inamdar (4):
>   pci: APM X-Gene PCIe controller driver
>   arm64: dts: APM X-Gene PCIe device tree nodes
>   dt-bindings: pci: xgene pcie device tree bindings
>   MAINTAINERS: entry for APM X-Gene PCIe host driver
>
>  .../devicetree/bindings/pci/xgene-pci.txt  |   52 ++
>  MAINTAINERS|7 +
>  arch/arm64/boot/dts/apm-mustang.dts|8 +
>  arch/arm64/boot/dts/apm-storm.dtsi |  155 
>  drivers/pci/host/Kconfig   |   10 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pci-xgene.c   |  784 
> 
>  7 files changed, 1017 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
>  create mode 100644 drivers/pci/host/pci-xgene.c
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] serial: uart: add hw flow control support configuration

[Dann Frazier]

On Wed, Jun 11, 2014 at 2:53 PM, Murali Karicheri  wrote:
> On 5/28/2014 4:04 PM, Dann Frazier wrote:
>>
>> On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri 
>> wrote:
>>>
>>> 8250 uart driver currently supports only software assisted hw flow
>>> control. The software assisted hw flow control maintains a hw_stopped
>>> flag in the tty structure to stop and start transmission and use modem
>>> status interrupt for the event to drive the handshake signals. This is
>>> not needed if hw has flow control capabilities. This patch adds a
>>> DT attribute for enabling hw flow control for a uart port. Also skip
>>> stop and start if this flag is present in flag field of the port
>>> structure.
>>
>> ubuntu@hwflow:~$ sudo stty -a --file /dev/ttyS0 |tr ' ' '\n' | grep
>> crtscts
>> crtscts
>> ubuntu@hwflow:~$ ls
>> /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
>> /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
>> ubuntu@hwflow:~$ python
>> Python 2.7.6 (default, Mar 22 2014, 22:58:30)
>> [GCC 4.8.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>
>>>>> UPF_HARDWARE_FLOW = 1 << 21
>>>>> if 0xB920 & UPF_HARDWARE_FLOW:
>>
>> ... print "OK"
>> ...
>> OK
>>
>> Hope that's a reasonable test case. Test fails when booted w/o
>> has-hw-flow-control attribute.
>>
>> Tested-by: dann frazier 
>
> What is the verdict? pass/fail? Ok/Not OK to merge?

Murali,

 It is working for me, and appears to already be Linus' tree.

  -dann

> Murali
>
>>> Signed-off-by: Murali Karicheri 
>>>
>>> CC: Rob Herring 
>>> CC: Pawel Moll 
>>> CC: Mark Rutland 
>>> CC: Ian Campbell 
>>> CC: Kumar Gala 
>>> CC: Randy Dunlap 
>>> CC: Greg Kroah-Hartman 
>>> CC: Jiri Slaby 
>>> CC: Santosh Shilimkar 
>>> ---
>>>   .../devicetree/bindings/serial/of-serial.txt   |1 +
>>>   drivers/tty/serial/8250/8250_core.c|6 --
>>>   drivers/tty/serial/of_serial.c |4 
>>>   drivers/tty/serial/serial_core.c   |   12 +---
>>>   4 files changed, 18 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
>>> b/Documentation/devicetree/bindings/serial/of-serial.txt
>>> index 1928a3e..7705477 100644
>>> --- a/Documentation/devicetree/bindings/serial/of-serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
>>> @@ -37,6 +37,7 @@ Optional properties:
>>>   - auto-flow-control: one way to enable automatic flow control support.
>>> The
>>> driver is allowed to detect support for the capability even without
>>> this
>>> property.
>>> +- has-hw-flow-control: the hardware has flow control capability.
>>>
>>>   Example:
>>>
>>> diff --git a/drivers/tty/serial/8250/8250_core.c
>>> b/drivers/tty/serial/8250/8250_core.c
>>> index 0e1bf88..b69aff2 100644
>>> --- a/drivers/tty/serial/8250/8250_core.c
>>> +++ b/drivers/tty/serial/8250/8250_core.c
>>> @@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port,
>>> struct ktermios *termios,
>>>   * the trigger, or the MCR RTS bit is cleared.  In the case
>>> where
>>>   * the remote UART is not using CTS auto flow control, we must
>>>   * have sufficient FIFO entries for the latency of the remote
>>> -* UART to respond.  IOW, at least 32 bytes of FIFO.
>>> +* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
>>> +* AFE if hw flow control is supported
>>>   */
>>> -   if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
>>> +   if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32))
>>> ||
>>> +   (port->flags & UPF_HARD_FLOW)) {
>>>  up->mcr &= ~UART_MCR_AFE;
>>>  if (termios->c_cflag & CRTSCTS)
>>>  up->mcr |= UART_MCR_AFE;
>>> diff --git a/drivers/tty/serial/of_serial.c
>>> b/drivers/tty/serial/of_serial.c
>>> index 9924660..77ec6a1 100644
>>> --- a/drivers/tty/serial/of_serial.c
>>> +++ b/drivers/tty/

Re: [PATCH v2] serial: uart: add hw flow control support configuration

[Dann Frazier]

On Thu, May 1, 2014 at 1:04 PM, Murali Karicheri  wrote:
> 8250 uart driver currently supports only software assisted hw flow
> control. The software assisted hw flow control maintains a hw_stopped
> flag in the tty structure to stop and start transmission and use modem
> status interrupt for the event to drive the handshake signals. This is
> not needed if hw has flow control capabilities. This patch adds a
> DT attribute for enabling hw flow control for a uart port. Also skip
> stop and start if this flag is present in flag field of the port
> structure.

ubuntu@hwflow:~$ sudo stty -a --file /dev/ttyS0 |tr ' ' '\n' | grep crtscts
crtscts
ubuntu@hwflow:~$ ls /proc/device-tree/soc/serial@1c021000/has-hw-flow-control
/proc/device-tree/soc/serial@1c021000/has-hw-flow-control
ubuntu@hwflow:~$ python
Python 2.7.6 (default, Mar 22 2014, 22:58:30)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> UPF_HARDWARE_FLOW = 1 << 21
>>> if 0xB920 & UPF_HARDWARE_FLOW:
... print "OK"
...
OK

Hope that's a reasonable test case. Test fails when booted w/o
has-hw-flow-control attribute.

Tested-by: dann frazier 

>
> Signed-off-by: Murali Karicheri 
>
> CC: Rob Herring 
> CC: Pawel Moll 
> CC: Mark Rutland 
> CC: Ian Campbell 
> CC: Kumar Gala 
> CC: Randy Dunlap 
> CC: Greg Kroah-Hartman 
> CC: Jiri Slaby 
> CC: Santosh Shilimkar 
> ---
>  .../devicetree/bindings/serial/of-serial.txt   |1 +
>  drivers/tty/serial/8250/8250_core.c|6 --
>  drivers/tty/serial/of_serial.c |4 
>  drivers/tty/serial/serial_core.c   |   12 +---
>  4 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt 
> b/Documentation/devicetree/bindings/serial/of-serial.txt
> index 1928a3e..7705477 100644
> --- a/Documentation/devicetree/bindings/serial/of-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
> @@ -37,6 +37,7 @@ Optional properties:
>  - auto-flow-control: one way to enable automatic flow control support. The
>driver is allowed to detect support for the capability even without this
>property.
> +- has-hw-flow-control: the hardware has flow control capability.
>
>  Example:
>
> diff --git a/drivers/tty/serial/8250/8250_core.c 
> b/drivers/tty/serial/8250/8250_core.c
> index 0e1bf88..b69aff2 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -2338,9 +2338,11 @@ serial8250_do_set_termios(struct uart_port *port, 
> struct ktermios *termios,
>  * the trigger, or the MCR RTS bit is cleared.  In the case where
>  * the remote UART is not using CTS auto flow control, we must
>  * have sufficient FIFO entries for the latency of the remote
> -* UART to respond.  IOW, at least 32 bytes of FIFO.
> +* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
> +* AFE if hw flow control is supported
>  */
> -   if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
> +   if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32)) ||
> +   (port->flags & UPF_HARD_FLOW)) {
> up->mcr &= ~UART_MCR_AFE;
> if (termios->c_cflag & CRTSCTS)
> up->mcr |= UART_MCR_AFE;
> diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
> index 9924660..77ec6a1 100644
> --- a/drivers/tty/serial/of_serial.c
> +++ b/drivers/tty/serial/of_serial.c
> @@ -182,6 +182,10 @@ static int of_platform_serial_probe(struct 
> platform_device *ofdev)
>   "auto-flow-control"))
> port8250.capabilities |= UART_CAP_AFE;
>
> +   if (of_property_read_bool(ofdev->dev.of_node,
> + "has-hw-flow-control"))
> +   port8250.port.flags |= UPF_HARD_FLOW;
> +
> ret = serial8250_register_8250_port();
> break;
> }
> diff --git a/drivers/tty/serial/serial_core.c 
> b/drivers/tty/serial/serial_core.c
> index b68550d..851707a 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -174,8 +174,12 @@ static int uart_port_startup(struct tty_struct *tty, 
> struct uart_state *state,
> if (tty->termios.c_cflag & CBAUD)
> uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
> }
>

lustre virtual block device doesn't build w/ CONFIG_ARM64_64K_PAGES=y

[dann frazier]

With current git, lustre fails to build with CONFIG_ARM64_64K_PAGES=y
and CONFIG_LUSTRE_LLITE_LLOOP=m:

make -f scripts/Makefile.build obj=drivers/staging/lustre/lustre/llite
  gcc -Wp,-MD,drivers/staging/lustre/lustre/llite/.lloop.o.d  -nostdinc 
-isystem /usr/lib/gcc/aarch64-linux-gnu/4.8/include -I./arch/arm64/include 
-Iarch/arm64/include/generated  -Iinclude -I./arch/arm64/include/uapi 
-Iarch/arm64/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi 
-include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef 
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-Werror-implicit-function-declaration -Wno-format-security -mgeneral-regs-only 
-fno-delete-null-pointer-checks -O2 -Wframe-larger-than=1024 
-fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer 
-fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign 
-fno-strict-overflow -fconserve-stack -Werror=implicit-int 
-Werror=strict-prototypes -Idrivers/staging/lustre/include/ 
-Idrivers/staging/lustre/lustre/llite/../include  -DMODULE  
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(lloop)"  
-D"KBUILD_MODNAME=KBUILD_STR(llite_lloop)" -c -o 
drivers/staging/lustre/lustre/llite/.tmp_lloop.o 
drivers/staging/lustre/lustre/llite/lloop.c
drivers/staging/lustre/lustre/llite/lloop.c: In function ‘loop_set_fd’:
drivers/staging/lustre/lustre/llite/lloop.c:523:78: error: duplicate case value
  CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
  ^
drivers/staging/lustre/lustre/llite/lloop.c:523:18: error: previously used here
  CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
  ^
scripts/Makefile.build:257: recipe for target 
'drivers/staging/lustre/lustre/llite/lloop.o' failed
make[5]: *** [drivers/staging/lustre/lustre/llite/lloop.o] Error 1
scripts/Makefile.build:404: recipe for target 
'drivers/staging/lustre/lustre/llite' failed
make[4]: *** [drivers/staging/lustre/lustre/llite] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging/lustre/lustre' 
failed
make[3]: *** [drivers/staging/lustre/lustre] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging/lustre' failed
make[2]: *** [drivers/staging/lustre] Error 2
scripts/Makefile.build:404: recipe for target 'drivers/staging' failed
make[1]: *** [drivers/staging] Error 2
Makefile:893: recipe for target 'drivers' failed
make: *** [drivers] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

[Dann Frazier]

On Fri, Jun 20, 2014 at 5:18 PM, Iyappan Subramanian
 wrote:
> This patch adds network driver for APM X-Gene SoC ethernet.
>
> Signed-off-by: Iyappan Subramanian 
> Signed-off-by: Ravi Patel 
> Signed-off-by: Keyur Chudgar 
> ---
>  drivers/net/ethernet/Kconfig   |   1 +
>  drivers/net/ethernet/Makefile  |   1 +
>  drivers/net/ethernet/apm/Kconfig   |   1 +
>  drivers/net/ethernet/apm/Makefile  |   5 +
>  drivers/net/ethernet/apm/xgene/Kconfig |   9 +
>  drivers/net/ethernet/apm/xgene/Makefile|   6 +
>  .../net/ethernet/apm/xgene/xgene_enet_ethtool.c| 125 +++
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 848 +++
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 394 +
>  drivers/net/ethernet/apm/xgene/xgene_enet_main.c   | 939 
> +
>  drivers/net/ethernet/apm/xgene/xgene_enet_main.h   | 109 +++
>  11 files changed, 2438 insertions(+)
>  create mode 100644 drivers/net/ethernet/apm/Kconfig
>  create mode 100644 drivers/net/ethernet/apm/Makefile
>  create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig
>  create mode 100644 drivers/net/ethernet/apm/xgene/Makefile
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h
[...]
> +static struct xgene_enet_desc_ring *xgene_enet_create_desc_ring(
> +   struct net_device *ndev, u32 ring_num,
> +   enum xgene_enet_ring_cfgsize cfgsize, u32 ring_id)
> +{
> +   struct xgene_enet_desc_ring *ring;
> +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
> +   struct device *dev = >pdev->dev;
> +   u32 size;
> +
> +   ring = devm_kzalloc(dev, sizeof(struct xgene_enet_desc_ring),
> +   GFP_KERNEL);
> +   if (!ring)
> +   return NULL;
> +
> +   ring->ndev = ndev;
> +   ring->num = ring_num;
> +   ring->cfgsize = cfgsize;
> +   ring->id = ring_id;
> +
> +   size = xgene_enet_get_ring_size(dev, cfgsize);
> +   ring->desc_addr = dma_zalloc_coherent(dev, size, >dma,
> + GFP_KERNEL);

Iyappan,
When testing this driver on a 3.16-rc2 base, I'm finding that
desc_addr gets assigned to NULL here, which results in an oops later
on (see below).

I wasn't seeing this before (3.15 base), so I'm guessing something
changed upstream, or in my config, to change this behavior. But it
does illuminate a place where we could maybe use some better error
handling (also see below).

> +   if (!ring->desc_addr)
> +   goto err;
> +   ring->size = size;
> +
> +   ring->cmd_base = pdata->ring_cmd_addr + (ring->num << 6);
> +   ring->cmd = ring->cmd_base + INC_DEC_CMD_ADDR;
> +   pdata->rm = RM3;
> +   ring = xgene_enet_setup_ring(ring);
> +   netdev_dbg(ndev, "ring info: num=%d  size=%d  id=%d  slots=%d\n",
> +  ring->num, ring->size, ring->id, ring->slots);
> +
> +   return ring;
> +err:
> +   dma_free_coherent(dev, size, ring->desc_addr, ring->dma);
> +   devm_kfree(dev, ring);
> +
> +   return NULL;
> +}
> +
> +static u16 xgene_enet_get_ring_id(enum xgene_ring_owner owner, u8 bufnum)
> +{
> +   return (owner << 6) | (bufnum & GENMASK(5, 0));
> +}
> +
> +static int xgene_enet_create_desc_rings(struct net_device *ndev)
> +{
> +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
> +   struct device *dev = >pdev->dev;
> +   struct xgene_enet_desc_ring *rx_ring, *tx_ring, *cp_ring;
> +   struct xgene_enet_desc_ring *buf_pool = NULL;
> +   u8 cpu_bufnum = 0, eth_bufnum = 0;
> +   u8 bp_bufnum = 0x20;
> +   u16 ring_id, ring_num = 0;
> +   int ret;
> +
> +   /* allocate rx descriptor ring */
> +   ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
> +   rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
> + RING_CFGSIZE_16KB, ring_id);
> +   if (IS_ERR_OR_NULL(rx_ring)) {
> +   ret = PTR_ERR(rx_ring);
> +   goto err;
> +   }

Here we test for IS_ERR_OR_NULL. In the oops I'm hitting, rx_ring is
NULL here - but PTR_ERR() apparently returns 0 in that case. So this
function ends up returning no error.

> +   /* allocate buffer pool for receiving packets */
> +   ring_id = xgene_enet_get_ring_id(RING_OWNER_ETH0, bp_bufnum++);
> +   buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
> +  RING_CFGSIZE_2KB, ring_id);
> +   if (IS_ERR_OR_NULL(buf_pool)) {
> +   ret = PTR_ERR(buf_pool);
> +   goto 

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Wed, Feb 14, 2018 at 8:42 AM, John Garry  wrote:
> On 13/02/2018 22:57, dann frazier wrote:
>>
>> On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote:
>>>
>>> From: Zhichang Yuan 
>>>
>>> After introducing the new generic I/O space management in logic pio, the
>>> original PCI MMIO relevant helpers need to be updated based on the new
>>> interfaces.
>>> This patch adapts the corresponding code to match the changes introduced
>>> by logic pio.
>>>
>>> Signed-off-by: Zhichang Yuan 
>>> Signed-off-by: Gabriele Paoloni 
>>> Signed-off-by: Arnd Bergmann #earlier draft
>>> Acked-by: Bjorn Helgaas 
>>
>>
>> I saw that Bjorn Acked this back in v6, but it seems like the code in
>> pci.c was reworked a bit for v7 onwards and I didn't see a follow-up
>> review (apologies if I just missed it). In which case, maybe his Ack
>> should have the "#earlier draft" tag as well?
>>
>
> Hi Dann,
>
> I see Bjorn acked again later on in the series, here:
> https://lkml.org/lkml/2017/5/26/612

Yep, you're right, sorry for missing that :)

>
>>> ---
>>>  drivers/pci/pci.c| 95
>>> +---
>>>  include/asm-generic/io.h |  2 +-
>>>  2 files changed, 18 insertions(+), 79 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 07290a3..8aa5c54 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -22,6 +22,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -3440,17 +3441,6 @@ int pci_request_regions_exclusive(struct pci_dev
>>> *pdev, const char *res_name)
>>>  }
>>>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>>>
>>> -#ifdef PCI_IOBASE
>>> -struct io_range {
>>> -   struct list_head list;
>>> -   phys_addr_t start;
>>> -   resource_size_t size;
>>> -};
>>> -
>>> -static LIST_HEAD(io_range_list);
>>> -static DEFINE_SPINLOCK(io_range_lock);
>>> -#endif
>>> -
>>>  /*
>>>   * Record the PCI IO range (expressed as CPU physical address + size).
>>>   * Return a negative value if an error has occured, zero otherwise
>>> @@ -3458,51 +3448,28 @@ struct io_range {
>>>  int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t
>>> addr,
>>> resource_size_t size)
>>>  {
>>> -   int err = 0;
>>> -
>>> +   int ret = 0;
>>>  #ifdef PCI_IOBASE
>>> -   struct io_range *range;
>>> -   resource_size_t allocated_size = 0;
>>> -
>>> -   /* check if the range hasn't been previously recorded */
>>> -   spin_lock(_range_lock);
>>> -   list_for_each_entry(range, _range_list, list) {
>>> -   if (addr >= range->start && addr + size <= range->start +
>>> size) {
>>> -   /* range already registered, bail out */
>>> -   goto end_register;
>>> -   }
>>> -   allocated_size += range->size;
>>> -   }
>>> +   struct logic_pio_hwaddr *range;
>>>
>>> -   /* range not registed yet, check for available space */
>>> -   if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
>>> -   /* if it's too big check if 64K space can be reserved */
>>> -   if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
>>> -   err = -E2BIG;
>>> -   goto end_register;
>>> -   }
>>> -
>>> -   size = SZ_64K;
>>> -   pr_warn("Requested IO range too big, new size set to
>>> 64K\n");
>>> -   }
>>> +   if (!size || addr + size < addr)
>>> +   return -EINVAL;
>>>
>>> -   /* add the range to the list */
>>> range = kzalloc(sizeof(*range), GFP_ATOMIC);
>>> -   if (!range) {
>>> -   err = -ENOMEM;
>>> -   goto end_register;
>>> -   }
>>> +   if (!range)
>>> +   return -ENOMEM;
>>>
>>> -   range->start = addr;
>>> +   range->fwnode = fwnode;
>>> range->size =

Re: [PATCH v14 0/9] LPC: legacy ISA I/O support

[dann frazier]

  MAINTAINERS|   7 +
>  drivers/acpi/pci_root.c|   8 +-
>  drivers/acpi/scan.c|  14 +
>  drivers/bus/Kconfig|   8 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 646 
> +
>  drivers/of/address.c   |  96 ++-
>  drivers/pci/pci.c  |  95 +--
>  include/asm-generic/io.h   |   4 +-
>  include/linux/logic_pio.h  | 131 +
>  include/linux/pci.h|   3 +-
>  lib/Kconfig|  15 +
>  lib/Makefile   |   2 +
>  lib/logic_pio.c| 285 +
>  15 files changed, 1250 insertions(+), 98 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c

Tested this version on a D05 board, no problems. So, for the series:

Tested-by: dann frazier 

Re: [PATCH 1/4] i2c: xlp9xx: return ENXIO on slave address NACK

[dann frazier]

On Tue, Jan 30, 2018 at 7:28 AM, George Cherian
 wrote:
> Gentle Ping on this series.

I've been using these on a few Cavium Sabre boards, which previously
had an unusable system interface (/dev/ipmi) due to timeouts or just
enumerations failures. So, fwiw:

Tested-by: dann frazier 

 -dann

> On 01/18/2018 11:09 AM, George Cherian wrote:
>>
>> From: Dmitry Bazhenov 
>>
>> Fix the driver violation of the common practice to return
>> ENXIO error on a slave address NACK.
>>
>> Signed-off-by: Dmitry Bazhenov 
>> Signed-off-by: George Cherian 
>> ---
>>   drivers/i2c/busses/i2c-xlp9xx.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-xlp9xx.c
>> b/drivers/i2c/busses/i2c-xlp9xx.c
>> index b970bf8..6d78cdc 100644
>> --- a/drivers/i2c/busses/i2c-xlp9xx.c
>> +++ b/drivers/i2c/busses/i2c-xlp9xx.c
>> @@ -324,7 +324,8 @@ static int xlp9xx_i2c_xfer_msg(struct xlp9xx_i2c_dev
>> *priv, struct i2c_msg *msg,
>> dev_dbg(priv->dev, "transfer error %x!\n", priv->msg_err);
>> if (priv->msg_err & XLP9XX_I2C_INTEN_BUSERR)
>> xlp9xx_i2c_init(priv);
>> -   return -EIO;
>> +   return (priv->msg_err & XLP9XX_I2C_INTEN_NACKADDR) ?
>> +   -ENXIO : -EIO;
>> }
>> if (timeleft == 0) {
>>
>
> Regards
> -George

Re: [PATCH v10 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

[dann frazier]

On Fri, Oct 27, 2017 at 05:11:24PM +0100, Gabriele Paoloni wrote:
> From: "zhichang.yuan" 
> 
> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
> I/O port addresses. This patch implements the LPC host controller driver
> which perform the I/O operations on the underlying hardware.
> We don't want to touch those existing peripherals' driver, such as ipmi-bt.
> So this driver applies the indirect-IO introduced in the previous patch
> after registering an indirect-IO node to the indirect-IO devices list which
> will be searched in the I/O accessors to retrieve the host-local I/O port.
> 
> Signed-off-by: Zou Rongrong 
> Signed-off-by: zhichang.yuan 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Rob Herring  #dts part
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  drivers/bus/Kconfig|   9 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 526 
> +
>  4 files changed, 569 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..213181f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,33 @@
> +Hisilicon Hip06 low-pin-count device
> +  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> +  provides I/O access to some legacy ISA devices.
> +  Hip06 is based on arm64 architecture where there is no I/O space. So, the
> +  I/O ports here are not cpu addresses, and there is no 'ranges' property in
> +  LPC device node.
> +
> +Required properties:
> +- compatible:  value should be as follows:
> + (a) "hisilicon,hip06-lpc"
> + (b) "hisilicon,hip07-lpc"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the LPC register set is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicon,hip06-lpc";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + };
> +};
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 2408ea3..358eed3 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -64,6 +64,15 @@ config BRCMSTB_GISB_ARB
> arbiter. This driver provides timeout and target abort error handling
> and internal bus master decoding.
>  
> +config HISILICON_LPC
> + bool "Support for ISA I/O space on Hisilicon Hip0X"
> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST))
> + select LOGIC_PIO
> + select INDIRECT_PIO
> + help
> +   Driver needed for some legacy ISA devices attached to Low-Pin-Count
> +   on Hisilicon Hip0X SoC.
> +
>  config IMX_WEIM
>   bool "Freescale EIM DRIVER"
>   depends on ARCH_MXC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index cc6364b..28e3862 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
>  obj-$(CONFIG_ARM_CCN)+= arm-ccn.o
>  
>  obj-$(CONFIG_BRCMSTB_GISB_ARB)   += brcmstb_gisb.o
> +obj-$(CONFIG_HISILICON_LPC)  += hisi_lpc.o
>  obj-$(CONFIG_IMX_WEIM)   += imx-weim.o
>  obj-$(CONFIG_MIPS_CDMM)  += mips_cdmm.o
>  obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> new file mode 100644
> index 000..c885483
> --- /dev/null
> +++ b/drivers/bus/hisi_lpc.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + * Author: Zou Rongrong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: [PATCH v10 0/9] LPC: legacy ISA I/O support

[dann frazier]

On Fri, Oct 27, 2017 at 10:11 AM, Gabriele Paoloni
 wrote:
> From: gabriele paoloni 
>
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.

fwiw, I tested this on one of our D05 boards and verified that the
IPMI SI worked fine.

Tested-by: dann frazier 

[PATCH] net: hns: Avoid action name truncation

[dann frazier]

When longer interface names are used, the action names exposed in
/proc/interrupts and /proc/irq/* maybe truncated. For example, when
using the predictable name algorithm in systemd on a HiSilicon D05,
I see:

  ubuntu@d05-3:~$  grep enahisic2i0-tx /proc/interrupts | sed 's/.* //'
  enahisic2i0-tx0
  enahisic2i0-tx1
  [...]
  enahisic2i0-tx8
  enahisic2i0-tx9
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1
  enahisic2i0-tx1

Increase the max ring name length to allow for an interface name
of IFNAMSIZE. After this change, I now see:

  $ grep enahisic2i0-tx /proc/interrupts | sed 's/.* //'
  enahisic2i0-tx0
  enahisic2i0-tx1
  enahisic2i0-tx2
  [...]
  enahisic2i0-tx8
  enahisic2i0-tx9
  enahisic2i0-tx10
  enahisic2i0-tx11
  enahisic2i0-tx12
  enahisic2i0-tx13
  enahisic2i0-tx14
  enahisic2i0-tx15

Signed-off-by: dann frazier 
---
 drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index 3e62692af011..fa5b30f547f6 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -87,7 +87,7 @@ do { \
 
 #define HNAE_AE_REGISTER 0x1
 
-#define RCB_RING_NAME_LEN 16
+#define RCB_RING_NAME_LEN (IFNAMSIZ + 4)
 
 #define HNAE_LOWEST_LATENCY_COAL_PARAM 30
 #define HNAE_LOW_LATENCY_COAL_PARAM80
-- 
2.17.0

Re: [PATCH v12 6/9] LPC: Support the LPC host on Hip06/Hip07 with DT bindings

[dann frazier]

On Wed, Jan 24, 2018 at 12:36:22AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
> I/O port addresses. This patch implements the LPC host controller driver
> which perform the I/O operations on the underlying hardware.
> We don't want to touch those existing peripherals' driver, such as ipmi-bt.
> So this driver applies the indirect-IO introduced in the previous patch
> after registering an indirect-IO node to the indirect-IO devices list which
> will be searched in the I/O accessors to retrieve the host-local I/O port.
> 
> The driver config is set as a bool instead of a trisate. The reason
> here is that, by the very nature of the driver providing a logical
> PIO range, it does not make sense to have this driver as a loadable
> module. Another more specific reason is that the Huawei D03 board
> which includes hip06 SoC requires the LPC bus for UART console, so
> should be built in.
> 
> Signed-off-by: Zou Rongrong 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Rob Herring  #dts part
> ---
>  .../arm/hisilicon/hisilicon-low-pin-count.txt  |  33 ++
>  drivers/bus/Kconfig|   8 +
>  drivers/bus/Makefile   |   1 +
>  drivers/bus/hisi_lpc.c | 526 
> +
>  4 files changed, 568 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>  create mode 100644 drivers/bus/hisi_lpc.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 000..213181f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,33 @@
> +Hisilicon Hip06 low-pin-count device
> +  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> +  provides I/O access to some legacy ISA devices.
> +  Hip06 is based on arm64 architecture where there is no I/O space. So, the
> +  I/O ports here are not cpu addresses, and there is no 'ranges' property in
> +  LPC device node.
> +
> +Required properties:
> +- compatible:  value should be as follows:
> + (a) "hisilicon,hip06-lpc"
> + (b) "hisilicon,hip07-lpc"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the LPC register set is mapped.
> +
> +Note:
> +  The node name before '@' must be "isa" to represent the binding stick to 
> the
> +  ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b {
> + compatible = "hisilicon,hip06-lpc";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + };
> +};
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 57e011d..91debe4 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -65,6 +65,14 @@ config BRCMSTB_GISB_ARB
> arbiter. This driver provides timeout and target abort error handling
> and internal bus master decoding.
>  
> +config HISILICON_LPC
> + bool "Support for ISA I/O space on Hisilicon hip06/7"
> + depends on (ARM64 && (ARCH_HISI || COMPILE_TEST))
> + select INDIRECT_PIO
> + help
> +   Driver needed for some legacy ISA devices attached to Low-Pin-Count
> +   on Hisilicon hip06/7 SoC.
> +
>  config IMX_WEIM
>   bool "Freescale EIM DRIVER"
>   depends on ARCH_MXC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index 9bcd0bf..abc7a42 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
>  obj-$(CONFIG_ARM_CCN)+= arm-ccn.o
>  
>  obj-$(CONFIG_BRCMSTB_GISB_ARB)   += brcmstb_gisb.o
> +obj-$(CONFIG_HISILICON_LPC)  += hisi_lpc.o
>  obj-$(CONFIG_IMX_WEIM)   += imx-weim.o
>  obj-$(CONFIG_MIPS_CDMM)  += mips_cdmm.o
>  obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> new file mode 100644
> index 000..4ce089a
> --- /dev/null
> +++ b/drivers/bus/hisi_lpc.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan 
> + * Author: Zou Rongrong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * 

Re: [PATCH v13 4/9] PCI: Apply the new generic I/O management on PCI IO hosts

[dann frazier]

On Wed, Feb 14, 2018 at 01:45:28AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> After introducing the new generic I/O space management in logic pio, the
> original PCI MMIO relevant helpers need to be updated based on the new
> interfaces.
> This patch adapts the corresponding code to match the changes introduced
> by logic pio.
> 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann #earlier draft
> Acked-by: Bjorn Helgaas 

I saw that Bjorn Acked this back in v6, but it seems like the code in
pci.c was reworked a bit for v7 onwards and I didn't see a follow-up
review (apologies if I just missed it). In which case, maybe his Ack
should have the "#earlier draft" tag as well?

> ---
>  drivers/pci/pci.c| 95 
> +---
>  include/asm-generic/io.h |  2 +-
>  2 files changed, 18 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 07290a3..8aa5c54 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3440,17 +3441,6 @@ int pci_request_regions_exclusive(struct pci_dev 
> *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>  
> -#ifdef PCI_IOBASE
> -struct io_range {
> - struct list_head list;
> - phys_addr_t start;
> - resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
>  /*
>   * Record the PCI IO range (expressed as CPU physical address + size).
>   * Return a negative value if an error has occured, zero otherwise
> @@ -3458,51 +3448,28 @@ struct io_range {
>  int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
>   resource_size_t size)
>  {
> - int err = 0;
> -
> + int ret = 0;
>  #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - /* check if the range hasn't been previously recorded */
> - spin_lock(_range_lock);
> - list_for_each_entry(range, _range_list, list) {
> - if (addr >= range->start && addr + size <= range->start + size) 
> {
> - /* range already registered, bail out */
> - goto end_register;
> - }
> - allocated_size += range->size;
> - }
> + struct logic_pio_hwaddr *range;
>  
> - /* range not registed yet, check for available space */
> - if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> - /* if it's too big check if 64K space can be reserved */
> - if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> - err = -E2BIG;
> - goto end_register;
> - }
> -
> - size = SZ_64K;
> - pr_warn("Requested IO range too big, new size set to 64K\n");
> - }
> + if (!size || addr + size < addr)
> + return -EINVAL;
>  
> - /* add the range to the list */
>   range = kzalloc(sizeof(*range), GFP_ATOMIC);
> - if (!range) {
> - err = -ENOMEM;
> - goto end_register;
> - }
> + if (!range)
> + return -ENOMEM;
>  
> - range->start = addr;
> + range->fwnode = fwnode;
>   range->size = size;
> + range->hw_start = addr;
> + range->flags = PIO_CPU_MMIO;
>  
> - list_add_tail(>list, _range_list);
> -
> -end_register:
> - spin_unlock(_range_lock);
> + ret = logic_pio_register_range(range);
> + if (ret)
> + kfree(range);
>  #endif
>  
> - return err;
> + return ret;
>  }
>  
>  phys_addr_t pci_pio_to_address(unsigned long pio)
> @@ -3510,21 +3477,10 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>   phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
>  
>  #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - if (pio > IO_SPACE_LIMIT)
> + if (pio >= MMIO_UPPER_LIMIT)
>   return address;
>  
> - spin_lock(_range_lock);
> - list_for_each_entry(range, _range_list, list) {
> - if (pio >= allocated_size && pio < allocated_size + 
> range->size) {
> - address = range->start + pio - allocated_size;
> - break;
> - }
> - allocated_size += range->size;
> - }
> - spin_unlock(_range_lock);
> + address = logic_pio_to_hwaddr(pio);
>  #endif
>  
>   return address;
> @@ -3533,25 +3489,8 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
>  #ifdef PCI_IOBASE
> - struct io_range *res;
> - resource_size_t offset = 0;
> - unsigned long addr = -1;
> -
> - spin_lock(_range_lock);
> - list_for_each_entry(res, _range_list, list) {
> - if (address >= res->start && 

Re: [PATCH v13 1/9] LIB: Introduce a generic PIO mapping method

[dann frazier]

On Wed, Feb 14, 2018 at 01:45:25AM +0800, John Garry wrote:
> From: Zhichang Yuan 
> 
> In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and
> pci_pio_to_address()"), a new I/O space management was supported. With
> that driver, the I/O ranges configured for PCI/PCIe hosts on some
> architectures can be mapped to logical PIO, converted easily between
> CPU address and the corresponding logicial PIO. Based on this, PCI
> I/O devices can be accessed in a memory read/write way through the
> unified in/out accessors.
> 
> But on some archs/platforms, there are bus hosts which access I/O
> peripherals with host-local I/O port addresses rather than memory
> addresses after memory-mapped.
> 
> To support those devices, a more generic I/O mapping method is introduced
> here. Through this patch, both the CPU addresses and the host-local port
> can be mapped into the logical PIO space with different logical/fake PIOs.
> After this, all the I/O accesses to either PCI MMIO devices or host-local
> I/O peripherals can be unified into the existing I/O accessors defined in
> asm-generic/io.h and be redirected to the right device-specific hooks
> based on the input logical PIO.
> 
> Signed-off-by: Zhichang Yuan 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: John Garry 
> ---
>  include/asm-generic/io.h  |   2 +
>  include/linux/logic_pio.h | 131 ++
>  lib/Kconfig   |  15 +++
>  lib/Makefile  |   2 +
>  lib/logic_pio.c   | 272 
> ++
>  5 files changed, 422 insertions(+)
>  create mode 100644 include/linux/logic_pio.h
>  create mode 100644 lib/logic_pio.c
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index b4531e3..b7996a79 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -351,6 +351,8 @@ static inline void writesq(volatile void __iomem *addr, 
> const void *buffer,
>  #define IO_SPACE_LIMIT 0x
>  #endif
>  
> +#include 
> +
>  /*
>   * {in,out}{b,w,l}() access little endian I/O. {in,out}{b,w,l}_p() can be
>   * implemented on hardware that needs an additional delay for I/O accesses to
> diff --git a/include/linux/logic_pio.h b/include/linux/logic_pio.h
> new file mode 100644
> index 000..b3322fd
> --- /dev/null
> +++ b/include/linux/logic_pio.h
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Gabriele Paoloni 
> + * Author: Zhichang Yuan 
> + *
> + */
> +
> +#ifndef __LINUX_LOGIC_PIO_H__
> +#define __LINUX_LOGIC_PIO_H__
> +
> +#ifdef __KERNEL__
> +
> +#include 
> +
> +#define PIO_INDIRECT 0x01UL /* indirect IO flag */
> +#define PIO_CPU_MMIO 0x00UL /* memory mapped io flag */
> +
> +struct logic_pio_hwaddr {
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + resource_size_t hw_start;
> + resource_size_t io_start;
> + resource_size_t size; /* range size populated */
> + unsigned long flags;
> +
> + void *devpara;  /* private parameter of the host device */
> + struct hostio_ops *ops; /* ops operating on this node */
> +};
> +
> +struct hostio_ops {
> + u32 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
> + size_t dlen);
> + u32 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
> + size_t dlen, unsigned int count);
> + void (*pfouts)(void *devobj, unsigned long ptaddr,
> + const void *outbuf, size_t dlen, unsigned int count);
> +};
> +
> +#ifdef CONFIG_INDIRECT_PIO
> +u8 logic_inb(unsigned long addr);
> +void logic_outb(u8 value, unsigned long addr);
> +void logic_outw(u16 value, unsigned long addr);
> +void logic_outl(u32 value, unsigned long addr);
> +u16 logic_inw(unsigned long addr);
> +u32 logic_inl(unsigned long addr);
> +void logic_outb(u8 value, unsigned long addr);
> +void logic_outw(u16 value, unsigned long addr);
> +void logic_outl(u32 value, unsigned long addr);
> +void logic_insb(unsigned long addr, void *buffer, unsigned int count);
> +void logic_insl(unsigned long addr, void *buffer, unsigned int count);
> +void logic_insw(unsigned long addr, void *buffer, unsigned int count);
> +void logic_outsb(unsigned long addr, const void *buffer, unsigned int count);
> +void logic_outsw(unsigned long addr, const void *buffer, unsigned int count);
> +void logic_outsl(unsigned long addr, const void *buffer, unsigned int count);
> +
> +#ifndef inb
> +#define inb logic_inb
> +#endif
> +
> +#ifndef inw
> +#define inw logic_inw
> +#endif
> +
> +#ifndef inl
> +#define inl logic_inl
> +#endif
> +
> +#ifndef outb
> +#define outb logic_outb
> +#endif
> +
> +#ifndef outw
> +#define outw logic_outw
> +#endif
> +
> +#ifndef outl
> +#define outl logic_outl
> +#endif
> +
> +#ifndef insb
> +#define insb logic_insb
> +#endif
> +
> +#ifndef insw
> 

5.9-rc7 oops in nvkm_udevice_info() w/ GA100

[dann frazier]

hey,
  I'm seeing an Oops when nouveau loads (see below). I've verified
that this is because both device->chip and device->name are NULL prior
to the strncpy()s at the end of nvkm_udevice_info(). Bisect shows that
this started happening after:

commit 24d5ff40a732633dceab68c6559ba723784f4a68
Author: Karol Herbst 
Date: Tue Apr 28 18:54:02 2020 +0200

drm/nouveau/device: rework mmio mapping code to get rid of second map

Fixes warnings on GPUs with smaller a smaller mmio region like vGPUs.

Signed-off-by: Karol Herbst 
Signed-off-by: Ben Skeggs 

[ 213.131657] nouveau :07:00.0: unknown chipset (17a1)
[ 213.138547] nouveau :07:00.0: unknown chipset (17a1)
[ 213.144938] BUG: kernel NULL pointer dereference, address: 
[ 213.152704] #PF: supervisor read access in kernel mode
[ 213.158433] #PF: error_code(0x) - not-present page
[ 213.164162] PGD 0 P4D 0
[ 213.166985] Oops:  [#1] SMP NOPTI
[ 213.171068] CPU: 32 PID: 206 Comm: kworker/32:0 Not tainted 5.9.0-rc7+ #1
[ 213.178639] Hardware name: NVIDIA DGXA100
920-23687-2530-000/DGXA100, BIOS 0.25 06/30/2020
[ 213.187866] Workqueue: events work_for_cpu_fn
[ 213.192761] RIP: 0010:nvkm_udevice_mthd+0x1ed/0x7d0 [nouveau]
[ 213.199170] Code: 10 49 89 47 08 4d 85 c9 74 10 48 85 c0 74 0b 41 8b
51 70 48 29 d0 49 89 47 10 49 8b 86 c0 00 00 00 49 8d 7f 18 ba 10 00
00 00 <48> 8b 30 e8 6b 91 89 c0 49 8b 76 28 49 8d 7f 28 ba 40 00 00 00
e8
[ 213.220121] RSP: 0018:ae0619d47b48 EFLAGS: 00010246
[ 213.225948] RAX:  RBX: 9cefab819580 RCX: 00c6
[ 213.233907] RDX: 0010 RSI:  RDI: 9cef988f0578
[ 213.241864] RBP: ae0619d47b80 R08:  R09: 
[ 213.249813] R10: 0088 R11: 01320122 R12: 
[ 213.257762] R13: 0068 R14: 9cef6107c400 R15: 9cef988f0560
[ 213.265721] FS: () GS:9cefce00()
knlGS:
[ 213.274747] CS: 0010 DS:  ES:  CR0: 80050033
[ 213.281153] CR2:  CR3: 007f3019c000 CR4: 00350ee0
[ 213.289104] Call Trace:
[ 213.291854] ? nvkm_object_insert+0x6f/0x80 [nouveau]
[ 213.297509] nvkm_object_mthd+0x1a/0x30 [nouveau]
[ 213.302773] nvkm_ioctl_mthd+0x65/0x70 [nouveau]
[ 213.307940] nvkm_ioctl+0xf0/0x190 [nouveau]
[ 213.312735] nvkm_client_ioctl+0x12/0x20 [nouveau]
[ 213.318097] nvif_object_ioctl+0x4f/0x60 [nouveau]
[ 213.323460] nvif_object_mthd+0x9f/0x150 [nouveau]
[ 213.328822] ? nvif_object_ctor+0x14b/0x1d0 [nouveau]
[ 213.334473] nvif_device_ctor+0x61/0x70 [nouveau]
[ 213.339749] nouveau_cli_init+0x1a3/0x460 [nouveau]
[ 213.345215] ? nouveau_drm_device_init+0x3e/0x780 [nouveau]
[ 213.351454] nouveau_drm_device_init+0x77/0x780 [nouveau]
[ 213.357479] ? pci_read_config_word+0x27/0x40
[ 213.362337] ? pci_enable_device_flags+0x14f/0x170
[ 213.367705] nouveau_drm_probe+0x132/0x1f0 [nouveau]
[ 213.373241] local_pci_probe+0x48/0x80
[ 213.377419] work_for_cpu_fn+0x1a/0x30
[ 213.381598] process_one_work+0x1e8/0x3b0
[ 213.386068] worker_thread+0x53/0x420
[ 213.390149] kthread+0x12f/0x150
[ 213.393745] ? process_one_work+0x3b0/0x3b0
[ 213.398406] ? __kthread_bind_mask+0x70/0x70
[ 213.403169] ret_from_fork+0x22/0x30
[ 213.407153] Modules linked in: nouveau(+) mxm_wmi wmi video
nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua
amd64_edac_mod edac_mce_amd amd_energy kvm_amd kvm rapl efi_pstore
ipmi_ssif input_leds cdc_ether usbnet mii ccp k10temp acpi_ipmi
ipmi_si ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel ip_tables
x_tables autofs4 btrfs blake2b_generic raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib ses enclosure
hid_generic usbhid uas hid usb_storage ib_uverbs ib_core
crct10dif_pclmul crc32_pclmul ast ghash_clmulni_intel drm_vram_helper
aesni_intel drm_ttm_helper crypto_simd ttm cryptd drm_kms_helper
glue_helper syscopyarea sysfillrect sysimgblt mlx5_core fb_sys_fops
pci_hyperv_intf igb cec mpt3sas dca rc_core raid_class nvme tls
i2c_algo_bit scsi_transport_sas drm mlxfw xhci_pci nvme_core
xhci_pci_renesas i2c_piix4
[ 213.497060] CR2: 
[ 213.500755] ---[ end trace eed3a19f1f25ca74 ]---

Re: [for-next][PATCH 09/18] tracing: Move pipe reference to trace array instead of current_tracer

[dann frazier]

On Thu, Jul 02, 2020 at 05:58:21PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> If a process has the trace_pipe open on a trace_array, the current tracer
> for that trace array should not be changed. This was original enforced by a
> global lock, but when instances were introduced, it was moved to the
> current_trace. But this structure is shared by all instances, and a
> trace_pipe is for a single instance. There's no reason that a process that
> has trace_pipe open on one instance should prevent another instance from
> changing its current tracer. Move the reference counter to the trace_array
> instead.
> 
> This is marked as "Fixes" but is more of a clean up than a true fix.
> Backport if you want, but its not critical.

Thanks Steven! In case it helps backport consideration, I wanted to
note that this addresses an issue we've seen with users trying to
change current_tracer when they happen to have rasdaemon
installed. rasdaemon uses the trace_pipe interface at runtime, which
therefore blocks changing the current tracer. But of course, unless
you know about rasdaemon internals, it isn't exactly an obvious
failure mode.

  -dann

> Fixes: cf6ab6d9143b1 ("tracing: Add ref count to tracer for when they are 
> being read by pipe")
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  kernel/trace/trace.c | 12 ++--
>  kernel/trace/trace.h |  2 +-
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8241d1448d70..64c5b8146cca 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -5891,7 +5891,7 @@ int tracing_set_tracer(struct trace_array *tr, const 
> char *buf)
>   }
>  
>   /* If trace pipe files are being read, we can't change the tracer */
> - if (tr->current_trace->ref) {
> + if (tr->trace_ref) {
>   ret = -EBUSY;
>   goto out;
>   }
> @@ -6107,7 +6107,7 @@ static int tracing_open_pipe(struct inode *inode, 
> struct file *filp)
>  
>   nonseekable_open(inode, filp);
>  
> - tr->current_trace->ref++;
> + tr->trace_ref++;
>  out:
>   mutex_unlock(_types_lock);
>   return ret;
> @@ -6126,7 +6126,7 @@ static int tracing_release_pipe(struct inode *inode, 
> struct file *file)
>  
>   mutex_lock(_types_lock);
>  
> - tr->current_trace->ref--;
> + tr->trace_ref--;
>  
>   if (iter->trace->pipe_close)
>   iter->trace->pipe_close(iter);
> @@ -7428,7 +7428,7 @@ static int tracing_buffers_open(struct inode *inode, 
> struct file *filp)
>  
>   filp->private_data = info;
>  
> - tr->current_trace->ref++;
> + tr->trace_ref++;
>  
>   mutex_unlock(_types_lock);
>  
> @@ -7529,7 +7529,7 @@ static int tracing_buffers_release(struct inode *inode, 
> struct file *file)
>  
>   mutex_lock(_types_lock);
>  
> - iter->tr->current_trace->ref--;
> + iter->tr->trace_ref--;
>  
>   __trace_array_put(iter->tr);
>  
> @@ -8737,7 +8737,7 @@ static int __remove_instance(struct trace_array *tr)
>   int i;
>  
>   /* Reference counter for a newly created trace array = 1. */
> - if (tr->ref > 1 || (tr->current_trace && tr->current_trace->ref))
> + if (tr->ref > 1 || (tr->current_trace && tr->trace_ref))
>   return -EBUSY;
>  
>   list_del(>list);
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 13db4000af3f..f21607f87189 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -356,6 +356,7 @@ struct trace_array {
>   struct trace_event_file *trace_marker_file;
>   cpumask_var_t   tracing_cpumask; /* only trace on set CPUs */
>   int ref;
> + int trace_ref;
>  #ifdef CONFIG_FUNCTION_TRACER
>   struct ftrace_ops   *ops;
>   struct trace_pid_list   __rcu *function_pids;
> @@ -547,7 +548,6 @@ struct tracer {
>   struct tracer   *next;
>   struct tracer_flags *flags;
>   int enabled;
> - int ref;
>   boolprint_max;
>   boolallow_instances;
>  #ifdef CONFIG_TRACER_MAX_TRACE

Re: [for-next][PATCH 09/18] tracing: Move pipe reference to trace array instead of current_tracer

[dann frazier]

On Fri, Jul 31, 2020 at 3:16 PM Steven Rostedt  wrote:
>
> On Fri, 31 Jul 2020 13:33:45 -0600
> dann frazier  wrote:
>
> > > This is marked as "Fixes" but is more of a clean up than a true fix.
> > > Backport if you want, but its not critical.
> >
> > Thanks Steven! In case it helps backport consideration, I wanted to
> > note that this addresses an issue we've seen with users trying to
> > change current_tracer when they happen to have rasdaemon
> > installed. rasdaemon uses the trace_pipe interface at runtime, which
> > therefore blocks changing the current tracer. But of course, unless
> > you know about rasdaemon internals, it isn't exactly an obvious
> > failure mode.
>
> Ah, then this should probably be backported.
>
> When I push to Linus (during the next merge window) and it gets into
> Linus's tree. Feel free to send sta...@vger.kernel.org the sha1 of this
> commit, and ask for it to be backported for the above stated reason.

Will do.

 -dann

Re: [PATCH 4.4 17/70] crypto: arm64/sha - avoid non-standard inline asm tricks

[dann frazier]

On Mon, Nov 26, 2018 at 11:50:32AM +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.

fyi, I bisected a regression down to this commit. This apparently
causes an ADR_PREL_PG_HI21 relocation to be added to the sha{1,2}_ce
modules. Back in 4.4 ADR_PREL_PG_HI21 relocations were forbidden if
built with CONFIG_ARM64_ERRATUM_843419=y, so now the sha{1,2}_ce modules
fail to load:

[   37.866250] module sha1_ce: unsupported RELA relocation: 275

Looks like it should be an issue for 4.14.y as well, but I haven't yet
tested it.

  -dann

> From: Ard Biesheuvel 
> 
> commit f4857f4c2ee9aa4e2aacac1a845352b00197fb57 upstream.
> 
> Replace the inline asm which exports struct offsets as ELF symbols
> with proper const variables exposing the same values. This works
> around an issue with Clang which does not interpret the "i" (or "I")
> constraints in the same way as GCC.
> 
> Signed-off-by: Ard Biesheuvel 
> Tested-by: Matthias Kaehlcke 
> Signed-off-by: Herbert Xu 
> Signed-off-by: Nathan Chancellor 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  arch/arm64/crypto/sha1-ce-core.S |6 --
>  arch/arm64/crypto/sha1-ce-glue.c |   11 +++
>  arch/arm64/crypto/sha2-ce-core.S |6 --
>  arch/arm64/crypto/sha2-ce-glue.c |   13 +
>  4 files changed, 16 insertions(+), 20 deletions(-)
> 
> --- a/arch/arm64/crypto/sha1-ce-core.S
> +++ b/arch/arm64/crypto/sha1-ce-core.S
> @@ -82,7 +82,8 @@ ENTRY(sha1_ce_transform)
>   ldr dgb, [x0, #16]
>  
>   /* load sha1_ce_state::finalize */
> - ldr w4, [x0, #:lo12:sha1_ce_offsetof_finalize]
> + ldr_l   w4, sha1_ce_offsetof_finalize, x4
> + ldr w4, [x0, x4]
>  
>   /* load input */
>  0:   ld1 {v8.4s-v11.4s}, [x1], #64
> @@ -132,7 +133,8 @@ CPU_LE(   rev32   v11.16b, v11.16b)
>* the padding is handled by the C code in that case.
>*/
>   cbz x4, 3f
> - ldr x4, [x0, #:lo12:sha1_ce_offsetof_count]
> + ldr_l   w4, sha1_ce_offsetof_count, x4
> + ldr x4, [x0, x4]
>   moviv9.2d, #0
>   mov x8, #0x8000
>   moviv10.2d, #0
> --- a/arch/arm64/crypto/sha1-ce-glue.c
> +++ b/arch/arm64/crypto/sha1-ce-glue.c
> @@ -17,9 +17,6 @@
>  #include 
>  #include 
>  
> -#define ASM_EXPORT(sym, val) \
> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> -
>  MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
>  MODULE_AUTHOR("Ard Biesheuvel ");
>  MODULE_LICENSE("GPL v2");
> @@ -32,6 +29,9 @@ struct sha1_ce_state {
>  asmlinkage void sha1_ce_transform(struct sha1_ce_state *sst, u8 const *src,
> int blocks);
>  
> +const u32 sha1_ce_offsetof_count = offsetof(struct sha1_ce_state, sst.count);
> +const u32 sha1_ce_offsetof_finalize = offsetof(struct sha1_ce_state, 
> finalize);
> +
>  static int sha1_ce_update(struct shash_desc *desc, const u8 *data,
> unsigned int len)
>  {
> @@ -52,11 +52,6 @@ static int sha1_ce_finup(struct shash_de
>   struct sha1_ce_state *sctx = shash_desc_ctx(desc);
>   bool finalize = !sctx->sst.count && !(len % SHA1_BLOCK_SIZE);
>  
> - ASM_EXPORT(sha1_ce_offsetof_count,
> -offsetof(struct sha1_ce_state, sst.count));
> - ASM_EXPORT(sha1_ce_offsetof_finalize,
> -offsetof(struct sha1_ce_state, finalize));
> -
>   /*
>* Allow the asm code to perform the finalization if there is no
>* partial data and the input is a round multiple of the block size.
> --- a/arch/arm64/crypto/sha2-ce-core.S
> +++ b/arch/arm64/crypto/sha2-ce-core.S
> @@ -88,7 +88,8 @@ ENTRY(sha2_ce_transform)
>   ld1 {dgav.4s, dgbv.4s}, [x0]
>  
>   /* load sha256_ce_state::finalize */
> - ldr w4, [x0, #:lo12:sha256_ce_offsetof_finalize]
> + ldr_l   w4, sha256_ce_offsetof_finalize, x4
> + ldr w4, [x0, x4]
>  
>   /* load input */
>  0:   ld1 {v16.4s-v19.4s}, [x1], #64
> @@ -136,7 +137,8 @@ CPU_LE(   rev32   v19.16b, v19.16b)
>* the padding is handled by the C code in that case.
>*/
>   cbz x4, 3f
> - ldr x4, [x0, #:lo12:sha256_ce_offsetof_count]
> + ldr_l   w4, sha256_ce_offsetof_count, x4
> + ldr x4, [x0, x4]
>   moviv17.2d, #0
>   mov x8, #0x8000
>   moviv18.2d, #0
> --- a/arch/arm64/crypto/sha2-ce-glue.c
> +++ b/arch/arm64/crypto/sha2-ce-glue.c
> @@ -17,9 +17,6 @@
>  #include 
>  #include 
>  
> -#define ASM_EXPORT(sym, val) \
> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> -
>  MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto 
> Extensions");
>  MODULE_AUTHOR("Ard Biesheuvel ");
>  MODULE_LICENSE("GPL v2");
> @@ -32,6 

Re: [PATCH 4.4 17/70] crypto: arm64/sha - avoid non-standard inline asm tricks

[dann frazier]

On Mon, Nov 23, 2020 at 01:49:07PM -0700, dann frazier wrote:
> On Mon, Nov 26, 2018 at 11:50:32AM +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> fyi, I bisected a regression down to this commit. This apparently
> causes an ADR_PREL_PG_HI21 relocation to be added to the sha{1,2}_ce
> modules. Back in 4.4 ADR_PREL_PG_HI21 relocations were forbidden if
> built with CONFIG_ARM64_ERRATUM_843419=y, so now the sha{1,2}_ce modules
> fail to load:
> 
> [   37.866250] module sha1_ce: unsupported RELA relocation: 275
> 
> Looks like it should be an issue for 4.14.y as well, but I haven't yet
> tested it.

This regression appears to be limited to 4.4.y. I didn't find it when
testing 4.9.y, and a 2nd bisection determined that it is because
4.9.y+ also contains a backport of commit 41c066f ("arm64: assembler:
make adr_l work in modules under KASLR"). That was pulled from 4.4.y
because it caused a build failure:

  https://www.spinics.net/lists/stable/msg179709.html

Shall I submit a revert of this patch for 4.4.y, or is it worth trying
to get a backport of 41c066f to work?

  -dann
  
> > From: Ard Biesheuvel 
> > 
> > commit f4857f4c2ee9aa4e2aacac1a845352b00197fb57 upstream.
> > 
> > Replace the inline asm which exports struct offsets as ELF symbols
> > with proper const variables exposing the same values. This works
> > around an issue with Clang which does not interpret the "i" (or "I")
> > constraints in the same way as GCC.
> > 
> > Signed-off-by: Ard Biesheuvel 
> > Tested-by: Matthias Kaehlcke 
> > Signed-off-by: Herbert Xu 
> > Signed-off-by: Nathan Chancellor 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  arch/arm64/crypto/sha1-ce-core.S |6 --
> >  arch/arm64/crypto/sha1-ce-glue.c |   11 +++
> >  arch/arm64/crypto/sha2-ce-core.S |6 --
> >  arch/arm64/crypto/sha2-ce-glue.c |   13 +
> >  4 files changed, 16 insertions(+), 20 deletions(-)
> > 
> > --- a/arch/arm64/crypto/sha1-ce-core.S
> > +++ b/arch/arm64/crypto/sha1-ce-core.S
> > @@ -82,7 +82,8 @@ ENTRY(sha1_ce_transform)
> > ldr dgb, [x0, #16]
> >  
> > /* load sha1_ce_state::finalize */
> > -   ldr w4, [x0, #:lo12:sha1_ce_offsetof_finalize]
> > +   ldr_l   w4, sha1_ce_offsetof_finalize, x4
> > +   ldr w4, [x0, x4]
> >  
> > /* load input */
> >  0: ld1 {v8.4s-v11.4s}, [x1], #64
> > @@ -132,7 +133,8 @@ CPU_LE( rev32   v11.16b, v11.16b)
> >  * the padding is handled by the C code in that case.
> >  */
> > cbz x4, 3f
> > -   ldr x4, [x0, #:lo12:sha1_ce_offsetof_count]
> > +   ldr_l   w4, sha1_ce_offsetof_count, x4
> > +   ldr x4, [x0, x4]
> > moviv9.2d, #0
> > mov x8, #0x8000
> > moviv10.2d, #0
> > --- a/arch/arm64/crypto/sha1-ce-glue.c
> > +++ b/arch/arm64/crypto/sha1-ce-glue.c
> > @@ -17,9 +17,6 @@
> >  #include 
> >  #include 
> >  
> > -#define ASM_EXPORT(sym, val) \
> > -   asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> > -
> >  MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
> >  MODULE_AUTHOR("Ard Biesheuvel ");
> >  MODULE_LICENSE("GPL v2");
> > @@ -32,6 +29,9 @@ struct sha1_ce_state {
> >  asmlinkage void sha1_ce_transform(struct sha1_ce_state *sst, u8 const *src,
> >   int blocks);
> >  
> > +const u32 sha1_ce_offsetof_count = offsetof(struct sha1_ce_state, 
> > sst.count);
> > +const u32 sha1_ce_offsetof_finalize = offsetof(struct sha1_ce_state, 
> > finalize);
> > +
> >  static int sha1_ce_update(struct shash_desc *desc, const u8 *data,
> >   unsigned int len)
> >  {
> > @@ -52,11 +52,6 @@ static int sha1_ce_finup(struct shash_de
> > struct sha1_ce_state *sctx = shash_desc_ctx(desc);
> > bool finalize = !sctx->sst.count && !(len % SHA1_BLOCK_SIZE);
> >  
> > -   ASM_EXPORT(sha1_ce_offsetof_count,
> > -  offsetof(struct sha1_ce_state, sst.count));
> > -   ASM_EXPORT(sha1_ce_offsetof_finalize,
> > -  offsetof(struct sha1_ce_state, finalize));
> > -
> > /*
> >  * Allow the asm code to perform the finalization if there is no
> >  * partial data and the input is a round multiple of the block size.
> > ---

Re: PROBLEM: 2.4.36.1 hangs.

[dann frazier]

On Tue, Feb 26, 2008 at 09:16:25AM +0100, Willy Tarreau wrote:
> On Mon, Feb 25, 2008 at 09:36:12PM -1000, Glen Nakamura wrote:
> > Aloha,
> > 
> > The "ext2_readdir() filp->f_pos fix" patch looks weird...
> > Perhaps the "filp->f_pos += le16_to_cpu(de->rec_len);" line should be
> > outside of the if statement like the indentation implies?
> 
> good catch! At least it's what is done in 2.6.

Yes, that certainly looks like a bug.

> > As it is, filp->f_pos gets corrupted if de->inode is ever zero...
> > This could possibly explain why I had a few strange directory
> > entries until I checked the filesystem with:
> > e2fsck -D -F -f /dev/{ext2 partition}
> > 
> > - glen
> > 
> > Here is an updated (untested) patch:
> 
> unfortunately, neither Dann nor me could reproduce the issue, so
> we'll wait for some victims^Wvolunteers to give it a try.

I'm now able to reliably reproduce it by creating/removing a chroot
(pbuilder create on a Debian system, though I'm sure a simpler test
exists). Correcting the le16_to_cpu placement as Glen described
fixes the issue for me.

> BTW, I notice that 2.6 also has one extra chunk that 2.4 does not
> have :
> 
> if (unlikely(need_revalidate)) {
> +   if (offset) {
> offset = ext2_validate_entry(kaddr, offset, 
> chunk_mask);
> +   filp->f_pos = (n< +   }
> +   filp->f_version = inode->i_version;
> need_revalidate = 0;
> }
> 
> I have no idea whether this part is needed, we'd better ask Theo or Al
> for some advices, as I'm not tempted by merging an uncertain patch when
> it comes to filesystems.

Looks like a test case may be available:
  
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2d7f2ea9c989853310c7f6e8be52cc090cc8e66b

-- 
dann frazier

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [SCSI] aacraid: Fix security hole

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Alan Cox.
(commit 60395bb60e0b5e4e0808ac8eb07a92f6c9cdea1f)

It has been build-tested only (I don't have the hardware).
CVE-2007-4308 was assigned for this issue.

Commit log from 2.6 follows.

  On the SCSI layer ioctl path there is no implicit permissions check for
  ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
  however allows all sorts of very admin only things to be done so should
  check.
---
 drivers/scsi/aacraid/linit.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Signed-off-by: dann frazier <[EMAIL PROTECTED]>

diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 57d0a40..c6d7bdf 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -683,6 +683,8 @@ static int aac_cfg_release(struct inode * inode, struct 
file * file )
 static int aac_cfg_ioctl(struct inode * inode,  struct file * file, unsigned 
int cmd, unsigned long arg )
 {
struct aac_dev *dev = aac_devices[MINOR(inode->i_rdev)];
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
return aac_do_ioctl(dev, cmd, (void *)arg);
 }
 
-- 
1.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
(commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)

CVE-2006-5753 was assigned for this issue.

I've built and boot-tested this, but I'm not sure how to exercise
these codepaths.

Commit log from 2.6 follows.

  CVE-2006-5753 is for a case where an inode can be marked bad, switching
  the ops to bad_inode_ops, which are all connected as:

  static int return_EIO(void)
  {
  return -EIO;
  }

  #define EIO_ERROR ((void *) (return_EIO))

  static struct inode_operations bad_inode_ops =
  {
  .create = bad_inode_create
  ...etc...

  The problem here is that the void cast causes return types to not be
  promoted, and for ops such as listxattr which expect more than 32 bits of
  return value, the 32-bit -EIO is interpreted as a large positive 64-bit
  number, i.e. 0xfffa instead of 0xfffa.

  This goes particularly badly when the return value is taken as a number of
  bytes to copy into, say, a user's buffer for example...

  I originally had coded up the fix by creating a return_EIO_ macro
  for each return type, like this:

  static int return_EIO_int(void)
  {
return -EIO;
  }
  #define EIO_ERROR_INT ((void *) (return_EIO_int))

  static struct inode_operations bad_inode_ops =
  {
.create = EIO_ERROR_INT,
  ...etc...

  but Al felt that it was probably better to create an EIO-returner for each
  actual op signature.  Since so few ops share a signature, I just went ahead
  & created an EIO function for each individual file & inode op that returns
  a value.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>
---
 fs/bad_inode.c |  191 +++-
 1 files changed, 161 insertions(+), 30 deletions(-)

diff --git a/fs/bad_inode.c b/fs/bad_inode.c
index 850ba5e..b6b1d7d 100644
--- a/fs/bad_inode.c
+++ b/fs/bad_inode.c
@@ -9,6 +9,76 @@
 #include 
 #include 
 #include 
+#include 
+
+static loff_t bad_file_llseek(struct file *file, loff_t offset, int origin)
+{
+   return -EIO;
+}
+
+static ssize_t bad_file_read(struct file *filp, char __user *buf,
+   size_t size, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_write(struct file *filp, const char __user *buf,
+   size_t siz, loff_t *ppos)
+{
+return -EIO;
+}
+
+static int bad_file_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+   return -EIO;
+}
+
+static unsigned int bad_file_poll(struct file *filp, poll_table *wait)
+{
+   return POLLERR;
+}
+
+static int bad_file_ioctl (struct inode *inode, struct file *filp,
+   unsigned int cmd, unsigned long arg)
+{
+   return -EIO;
+}
+
+static int bad_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   return -EIO;
+}
+
+static int bad_file_open(struct inode *inode, struct file *filp)
+{
+   return -EIO;
+}
+
+static int bad_file_flush(struct file *file)
+{
+   return -EIO;
+}
+
+static int bad_file_release(struct inode *inode, struct file *filp)
+{
+   return -EIO;
+}
+
+static int bad_file_fsync(struct file *file, struct dentry *dentry,
+   int datasync)
+{
+   return -EIO;
+}
+
+static int bad_file_fasync(int fd, struct file *filp, int on)
+{
+   return -EIO;
+}
+
+static int bad_file_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+   return -EIO;
+}
 
 /*
  * The follow_link operation is special: it must behave as a no-op
@@ -20,46 +90,107 @@ static int bad_follow_link(struct dentry *dent, struct 
nameidata *nd)
return vfs_follow_link(nd, ERR_PTR(-EIO));
 }
 
-static int return_EIO(void)
+static struct file_operations bad_file_ops =
+{
+   llseek: bad_file_llseek,
+   read:   bad_file_read,
+   write:  bad_file_write,
+   readdir:bad_file_readdir,
+   poll:   bad_file_poll,
+   ioctl:  bad_file_ioctl,
+   mmap:   bad_file_mmap,
+   open:   bad_file_open,
+   flush:  bad_file_flush,
+   release:bad_file_release,
+   fsync:  bad_file_fsync,
+   fasync: bad_file_fasync,
+   lock:   bad_file_lock,
+};
+
+static int bad_inode_create (struct inode *dir, struct dentry *dentry,
+   int mode)
 {
return -EIO;
 }
+  
+static struct dentry *bad_inode_lookup(struct inode *dir,
+   struct dentry *dentry)
+{
+   return ERR_PTR(-EIO);
+}
 
-#define EIO_ERROR ((void *) (return_EIO))
+static int bad_inode_link (struct dentry *old_dentry, struct inode *dir,
+   struct dentry *dentry)
+{
+   return -EIO;
+}
 
-static struct file_operations bad_file_ops =
+static int bad_inode_unlink(struct inode *dir, struct dentry *dentry)
 {
-   llseek: EIO_ERROR,
-   read:   EIO_ERROR,
-   write:  EIO_ERROR,
-   readdir:   

Re: [PATCH] 2.4: fix memory corruption from misinterpreted bad_inode_ops return values

[dann frazier]

On Thu, Jan 24, 2008 at 03:06:58PM -0600, Eric Sandeen wrote:
> Willy Tarreau wrote:
> > Hi Dann,
> > 
> > On Wed, Jan 23, 2008 at 11:12:12PM -0700, dann frazier wrote:
> >> This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
> >> (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)
> >>
> >> CVE-2006-5753 was assigned for this issue.
> >>
> >> I've built and boot-tested this, but I'm not sure how to exercise
> >> these codepaths.
> > 
> > I have no idea either. Let's consider that if nobody on the list knows
> > how to do so, I'll merge it since you did not notice any regression.
> > 
> > Thanks,
> > Willy
> > 
> 
> Sorry... here you go.  Forgot to post this sooner.  I hit it with
> this on 2.6.x
> 
> #include 
> #include 
> #include 
> 
> static int return_EIO(void)
> {
> return -EIO;
> }
> 
> int main(int argc, char ** argv)
> {
>   ssize_t error;
>   ssize_t realerror = -EIO;
>   ssize_t (*fn_ptr)(void);
> 
>   fn_ptr = (void *)return_EIO;
> 
>   error = (ssize_t)fn_ptr();
>   printf("and... error is %ld, should be %ld\n", error, realerror);
>   return 0;
> }

Thanks Eric. Sounds like my comment about exercising these code paths
wasn't too clear - the comments with your patch do make the issue
clear, and this program demonstrates the void cast promotion issue
well. I'm just not sure of a good way to demonstrate that my backport
of this patch doesn't break anything for 2.4.

-- 
dann frazier

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [PPPOE]: memory leak when socket is release()d before PPPIOCGCHAN has been called on it

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Florian Zumbiehl.
(commit 202a03acf9994076055df40ae093a5c5474ad0bd)

CVE-2007-2525 was assigned for this issue. It has been compile tested-only.

Commit log from 2.6 follows.

  below you find a patch that fixes a memory leak when a PPPoE socket is
  release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl
  ever has been called on it.

  This is somewhat of a security problem, too, since PPPoE sockets can be
  created by any user, so any user can easily allocate all the machine's
  RAM to non-swappable address space and thus DoS the system.

  Is there any specific reason for PPPoE sockets being available to any
  unprivileged process, BTW? After all, you need a packet socket for the
  discovery stage anyway, so it's unlikely that any unprivileged process
  will ever need to create a PPPoE socket, no? Allocating all session IDs
  for a known AC is a kind of DoS, too, after all - with Juniper ERXes,
  this is really easy, actually, since they don't ever assign session ids
  above 8000 ...

Signed-off-by: dann frazier <[EMAIL PROTECTED]>
---
 drivers/net/pppox.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/pppox.c b/drivers/net/pppox.c
index 7830e4d..4883c0f 100644
--- a/drivers/net/pppox.c
+++ b/drivers/net/pppox.c
@@ -67,7 +67,7 @@ void pppox_unbind_sock(struct sock *sk)
 {
/* Clear connection to ppp device, if attached. */
 
-   if (sk->state & (PPPOX_BOUND|PPPOX_ZOMBIE)) {
+   if (sk->state & (PPPOX_BOUND | PPPOX_CONNECTED | PPPOX_ZOMBIE)) {
ppp_unregister_channel(>protinfo.pppox->chan);
sk->state = PPPOX_DEAD;
}
-- 
1.5.3.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: USB: fix DoS in pwc USB video driver

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Oliver Neukum.
(commit 85237f202d46d55c1bffe0c5b1aa3ddc0f1dce4d)

CVE-2007-5093 was assigned for this issue.
This backport has been compile-tested only.

Commit log from 2.6 follows.

  the pwc driver has a disconnect method that waits for user space to
  close the device. This opens up an opportunity for a DoS attack,
  blocking the USB subsystem and making khubd's task busy wait in
  kernel space. This patch shifts freeing resources to close if an opened
  device is disconnected.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>
---
 drivers/usb/pwc-if.c |   50 +-
 drivers/usb/pwc.h|1 +
 2 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/pwc-if.c b/drivers/usb/pwc-if.c
index e458515..a1c3989 100644
--- a/drivers/usb/pwc-if.c
+++ b/drivers/usb/pwc-if.c
@@ -1055,11 +1055,16 @@ static int pwc_video_open(struct video_device *vdev, 
int mode)
return 0;
 }
 
+static void pwc_cleanup(struct pwc_device *pdev)
+{
+   video_unregister_device(>vdev);
+}
+
 /* Note that all cleanup is done in the reverse order as in _open */
 static void pwc_video_close(struct video_device *vdev)
 {
struct pwc_device *pdev;
-   int i;
+   int i, hint;
 
Trace(TRACE_OPEN, ">> video_close called(vdev = 0x%p).\n", vdev);
 
@@ -1083,8 +1088,9 @@ static void pwc_video_close(struct video_device *vdev)
pwc_isoc_cleanup(pdev);
pwc_free_buffers(pdev);
 
+   lock_kernel();
/* Turn off LEDS and power down camera, but only when not unplugged */
-   if (pdev->error_status != EPIPE) {
+   if (!pdev->unplugged) {
if (pwc_set_leds(pdev, 0, 0) < 0)
Info("Failed to set LED on/off time.\n");
if (power_save) {
@@ -1092,9 +1098,18 @@ static void pwc_video_close(struct video_device *vdev)
if (i < 0) 
Err("Failed to power down camera (%d)\n", i);
}
+   pdev->vopen = 0;
+   Trace(TRACE_OPEN, "<< video_close()\n");
+   } else {
+   pwc_cleanup(pdev);
+   /* Free memory (don't set pdev to 0 just yet) */
+   kfree(pdev);
+   /* search device_hint[] table if we occupy a slot, by any 
chance */
+   for (hint = 0; hint < MAX_DEV_HINTS; hint++)
+   if (device_hint[hint].pdev == pdev)
+   device_hint[hint].pdev = NULL;
}
-   pdev->vopen = 0;
-   Trace(TRACE_OPEN, "<< video_close()\n");
+   unlock_kernel();
 }
 
 /*
@@ -1897,19 +1912,20 @@ static void usb_pwc_disconnect(struct usb_device *udev, 
void *ptr)
/* Alert waiting processes */
wake_up_interruptible(>frameq);
/* Wait until device is closed */
-   while (pdev->vopen)
-   schedule();
-   /* Device is now closed, so we can safely unregister it */
-   Trace(TRACE_PROBE, "Unregistering video device in disconnect().\n");
-   video_unregister_device(>vdev); 
-
-   /* Free memory (don't set pdev to 0 just yet) */
-   kfree(pdev);
-
-   /* search device_hint[] table if we occupy a slot, by any chance */
-   for (hint = 0; hint < MAX_DEV_HINTS; hint++)
-   if (device_hint[hint].pdev == pdev)
-   device_hint[hint].pdev = NULL;
+   if(pdev->vopen) {
+   pdev->unplugged = 1;
+   } else {
+   /* Device is closed, so we can safely unregister it */
+   Trace(TRACE_PROBE, "Unregistering video device in 
disconnect().\n");
+   pwc_cleanup(pdev);
+   /* Free memory (don't set pdev to 0 just yet) */
+   kfree(pdev);
+   
+   /* search device_hint[] table if we occupy a slot, by any 
chance */
+   for (hint = 0; hint < MAX_DEV_HINTS; hint++)
+   if (device_hint[hint].pdev == pdev)
+   device_hint[hint].pdev = NULL;
+   }
 
unlock_kernel();
 }
diff --git a/drivers/usb/pwc.h b/drivers/usb/pwc.h
index b020769..999daf2 100644
--- a/drivers/usb/pwc.h
+++ b/drivers/usb/pwc.h
@@ -141,6 +141,7 @@ struct pwc_device
char vsnapshot; /* snapshot mode */
char vsync; /* used by isoc handler */
char vmirror;   /* for ToUCaM series */
+   char unplugged;
 
/* The image acquisition requires 3 to 4 steps:
   1. data is gathered in short packets from the USB controller
-- 
1.5.3.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4: [POWERPC] CHRP: Fix possible NULL pointer dereference

[dann frazier]

This is a 2.4 backport of a linux-2.6 change by Cyrill Gorcunov.
(commit 9ac71d00398674aaec664f30559f0a21d963862f)

CVE-2007-6694 was assigned for this issue.
This backport has been compile-tested only.

Commit log from 2.6 follows.

This fixes a possible NULL pointer dereference inside of strncmp() if
of_get_property() fails.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>

diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c
index 0ffbbd2..28747db 100644
--- a/arch/ppc/platforms/chrp_setup.c
+++ b/arch/ppc/platforms/chrp_setup.c
@@ -121,7 +121,7 @@ chrp_show_cpuinfo(struct seq_file *m)
seq_printf(m, "machine\t\t: CHRP %s\n", model);
 
/* longtrail (goldengate) stuff */
-   if (!strncmp(model, "IBM,LongTrail", 13)) {
+   if (model && !strncmp(model, "IBM,LongTrail", 13)) {
/* VLSI VAS96011/12 `Golden Gate 2' */
/* Memory banks */
sdramen = (in_le32((unsigned *)(gg2_pci_config_base+
@@ -210,14 +210,20 @@ static void __init sio_fixup_irq(const char *name, u8 
device, u8 level,
 static void __init sio_init(void)
 {
struct device_node *root;
+   const char *model;
 
-   if ((root = find_path_device("/")) &&
-   !strncmp(get_property(root, "model", NULL), "IBM,LongTrail", 13)) {
+   root = find_path_device("/");
+   if (!root)
+   return;
+
+   model = get_property(root, "model", NULL);
+   if (model && !strncmp(model, "IBM,LongTrail", 13)) {
/* logical device 0 (KBC/Keyboard) */
sio_fixup_irq("keyboard", 0, 1, 2);
/* select logical device 1 (KBC/Mouse) */
sio_fixup_irq("mouse", 1, 12, 2);
}
+
 }
 
 
-- 
1.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

hey,
  I'm seeing a regression when executing 'dmraid -r -c' in an arm64
QEMU guest, which I've bisected to the following commit:

  ca18d6f7 "block: Make most scsi_req_init() calls implicit"

I haven't yet had time to try and debug it yet, but wanted to get
the report out there before the weekend. Here's the crash:

[  138.519885] usercopy: kernel memory overwrite attempt detected to   
(null) () (6 bytes)
[  138.521562] kernel BUG at mm/usercopy.c:72!
[  138.522294] Internal error: Oops - BUG: 0 [#1] SMP
[  138.523105] Modules linked in: nls_utf8 isofs nls_iso8859_1 qemu_fw_cfg 
ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_decompress 
zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 
aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64 
sha1_ce virtio_net virtio_blk aes_neon_bs aes_neon_blk crypto_simd cryptd 
aes_arm64
[  138.531307] CPU: 62 PID: 2271 Comm: dmraid Not tainted 4.14.0-rc5+ #20
[  138.532512] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[  138.533796] task: 8003cba2e900 task.stack: 110e8000
[  138.534887] PC is at __check_object_size+0x114/0x200
[  138.535800] LR is at __check_object_size+0x114/0x200
[  138.536711] pc : [] lr : [] pstate: 
00400145
[  138.538073] sp : 110ebb00
[  138.538682] x29: 110ebb00 x28:  
[  138.539658] x27: d88e1110 x26: 8003e8d3d800 
[  138.540633] x25: 0802001d x24: 8003e1131920 
[  138.541621] x23: 0006 x22: 0006 
[  138.542596] x21:  x20: 0006 
[  138.543571] x19:  x18:  
[  138.544548] x17: 83380ce0 x16: 082dd3b0 
[  138.545525] x15: 093c8c08 x14: 6c756e2820202020 
[  138.546511] x13: 202020202020206f x12: 7420646574636574 
[  138.547489] x11: 093c9658 x10: 086ae800 
[  138.548466] x9 : 7265766f2079726f x8 : 0017 
[  138.549445] x7 : 6c756e3c2820296c x6 : 8003eeb51c28 
[  138.550434] x5 : 8003eeb51c28 x4 :  
[  138.551411] x3 : 8003eeb59ec8 x2 : d4a0cd0f45236000 
[  138.552388] x1 :  x0 : 0059 
[  138.553364] Process dmraid (pid: 2271, stack limit = 0x110e8000)
[  138.554593] Call trace:
[  138.555043] Exception stack(0x110eb9c0 to 0x110ebb00)
[  138.556214] b9c0: 0059  d4a0cd0f45236000 
8003eeb59ec8
[  138.557653] b9e0:  8003eeb51c28 8003eeb51c28 
6c756e3c2820296c
[  138.559082] ba00: 0017 7265766f2079726f 086ae800 
093c9658
[  138.560510] ba20: 7420646574636574 202020202020206f 6c756e2820202020 
093c8c08
[  138.561950] ba40: 082dd3b0 83380ce0  

[  138.563379] ba60: 0006  0006 
0006
[  138.564805] ba80: 8003e1131920 0802001d 8003e8d3d800 
d88e1110
[  138.566238] baa0:  110ebb00 082c0e5c 
110ebb00
[  138.567666] bac0: 082c0e5c 00400145 08e25a80 

[  138.569090] bae0: 0001 0006 110ebb00 
082c0e5c
[  138.570523] [] __check_object_size+0x114/0x200
[  138.571628] [] sg_io+0x120/0x438
[  138.572507] [] scsi_cmd_ioctl+0x594/0x728
[  138.573531] [] scsi_cmd_blk_ioctl+0x50/0x60
[  138.574594] [] virtblk_ioctl+0x60/0x80 [virtio_blk]
[  138.575769] [] blkdev_ioctl+0x5e4/0xb50
[  138.576756] [] block_ioctl+0x50/0x68
[  138.577698] [] do_vfs_ioctl+0xc4/0x940
[  138.578671] [] SyS_ioctl+0x8c/0xa8
[  138.579581] Exception stack(0x110ebec0 to 0x110ec000)
[  138.580752] bec0: 0005 2285 d88e10b8 
0006
[  138.582199] bee0:  0004 83416648 
0050
[  138.583623] bf00: 001d 0003 0012 
0011
[  138.585050] bf20: 83409000 00ff 8309dc70 
0531
[  138.586490] bf40: 8344a360 83380ce0 00dc 
83478948
[  138.587918] bf60: 0004 17ee7f90 0005 
17ede920
[  138.589346] bf80: 17ee7f60 0003 83416648 
17ee7f60
[  138.590785] bfa0: d88e1218 d88e1090 834166dc 
d88e1090
[  138.592215] bfc0: 83380cec 8000 0005 
001d
[  138.593649] bfe0:    

[  138.595091] [] el0_svc_naked+0x24/0x28
[  138.596071] Code: aa1403e5 aa1303e3 9119a0c0 97f9d96d (d421) 
[  138.597193] ---[ end trace b7eecd0b21001177 ]---

Here's the ioctl as 

Re: [PATCH v12 0/9] LPC: legacy ISA I/O support

[dann frazier]

On Tue, Jan 23, 2018 at 9:36 AM, John Garry  wrote:
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.
> ---
> | LPC host|
> | |
> ---
>  |
> _V___LPC
>   |   |
>   V   V
>  
>  |  BT(ipmi)|
>  
>
> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific
> LPC driver is needed to make LPC host generate the standard LPC I/O cycles 
> with
> the target peripherals'I/O port addresses. But on curent arm64 world, there is
> no real I/O accesses. All the I/O operations through in/out accessors are 
> based
> on MMIO ranges; on Hip06/Hip07 LPC the I/O accesses are performed through 
> driver
> specific accessors rather than MMIO.
> To solve this issue and keep the relevant existing peripherals' drivers 
> untouched,
> this patchset:
>- introduces a generic I/O space management framework, LIBIO, to support 
> I/O
>  operations on host controllers operating either on MMIO buses or on buses
>  requiring specific driver I/O accessors;
>- redefines the in/out accessors to provide a unified interface for both 
> MMIO
>  and driver specific I/O operations. Using LIBIO, th call of in/out() from
>  the host children drivers, such as ipmi-si, will be redirected to the
>  corresponding device-specific I/O hooks to perform the I/O accesses.
>
> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals 
> can
> be supported without any changes on the existing ipmi-si driver.
>
> The whole patchset has been tested on Hip07 D05 board both using DTB and ACPI.

fyi, tested successfully here as well on a D05:

Tested-by: dann frazier 

 -dann

> Differences to v11:
> - fixed build errors for i386, m68k, and tile
> - added a comment in LPC driver commit log why we set
>the kernel config as bool
> - some tidying logic_pio code
>
> Differences to v10:
> - dropped CONFIG_LOGIC_PIO. Reason is that CONFIG_PCI
>   depends on this, and CONFIG_PCI is a per-arch CONFIG.
>   So we would require all arch's kconfig to select this.
> - Addressed Dann Frazier's comments on LPC driver, and
>   sopme other cleanup
> - Moved logic_pio.h to be included in generic asm io.h
> - Fixed ACPI indirect IO host setup to handle >1 child
> - Relocated ACPI indirect IO host setup code to
>   drivers/acpi
> - Rebased to linux next-20180118
>
> Changes from v9:
>   - patch 2 has been split into 3 patches according to Bjorn comments on
> v9 thread
>   - patch 1 has been reworked accordign to Bjorn comments on v9
>   - now logic_pio_trans_hwaddr() has a sanity check to make sure the resource
> size fits into the assigned range
>   - in patch 5 the MFD framework has been used to probe the LPC children
> according to the suggestion from Mika Westerberg
>   - Maintaner has changed to Huawei Linuxarm mailing list
>
> Changes from v8:
>   - Simplified LIB IO framewrok
>   - Moved INDIRECT PIO ACPI framework under acpi/arm64
>   - Renamed occurrences of "lib io" and "indirect io" to "lib pio" and
> "indirect pio" to keep the patchset nomenclature consistent
>   - Removed Alignment reuqirements
>   - Moved LPC specific code out of ACPI common framework
>   - Now PIO indirect HW ranges can overlap
>   - Changed HiSilicon LPC driver maintainer (Gabriele Paoloni now) and split
> maintaner file modifications in a separate commit
>   - Removed the commit with the DT nodes support for hip06 and hip07 (to be
> pushed separately)
>   - Added a checking on ioport_map() not to break that function as Arnd points
> out in V7 review thread;
>   - fixed the compile issues on alpha, m68k;
>
> Changes from V7:
>   - Based on Arnd's comment, rename the LIBIO as LOGIC_PIO;
>   - Improved the mapping process in LOGIC_PIO to gain better efficiency when
> redirecting the I/O accesses to right device driver;
>   - To reduce the impact on PCI MMIO to a minimum, add a new
> CONFIG_INDIRECT_PIO for indirect-IO hosts/devices;
>   - Added a new ACPI handler for indirect-IO hosts/devices;
>   - Fixed the compile issues on V6;
>
> Changes from V6:
>   - According to the comments from Bjorn and Alex, merge PCI IO and 
> indirect-IO
> into

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

[dann frazier]

On Fri, Oct 20, 2017 at 11:30:55PM +, Bart Van Assche wrote:
> On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote:
> > hey,
> >   I'm seeing a regression when executing 'dmraid -r -c' in an arm64
> > QEMU guest, which I've bisected to the following commit:
> > 
> >   ca18d6f7 "block: Make most scsi_req_init() calls implicit"
> > 
> > I haven't yet had time to try and debug it yet, but wanted to get
> > the report out there before the weekend. Here's the crash:
> > 
> > [  138.519885] usercopy: kernel memory overwrite attempt detected to
> >(null) () (6 bytes)
> > [  138.521562] kernel BUG at mm/usercopy.c:72!
> > [  138.522294] Internal error: Oops - BUG: 0 [#1] SMP
> > [  138.523105] Modules linked in: nls_utf8 isofs nls_iso8859_1 qemu_fw_cfg 
> > ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi 
> > scsi_transport_iscsi ip_tables
> > x_tables autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 
> > async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
> > libcrc32c raid1 raid0
> > multipath linear aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce 
> > sha2_ce sha256_arm64 sha1_ce virtio_net virtio_blk aes_neon_bs aes_neon_blk 
> > crypto_simd cryptd
> > aes_arm64
> > [  138.531307] CPU: 62 PID: 2271 Comm: dmraid Not tainted 4.14.0-rc5+ #20
> > [  138.532512] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
> > 02/06/2015
> > [  138.533796] task: 8003cba2e900 task.stack: 110e8000
> > [  138.534887] PC is at __check_object_size+0x114/0x200
> > [  138.535800] LR is at __check_object_size+0x114/0x200
> > [  138.536711] pc : [] lr : [] pstate: 
> > 00400145
> > [  138.538073] sp : 110ebb00
> > [  138.538682] x29: 110ebb00 x28:  
> > [  138.539658] x27: d88e1110 x26: 8003e8d3d800 
> > [  138.540633] x25: 0802001d x24: 8003e1131920 
> > [  138.541621] x23: 0006 x22: 0006 
> > [  138.542596] x21:  x20: 0006 
> > [  138.543571] x19:  x18:  
> > [  138.544548] x17: 83380ce0 x16: 082dd3b0 
> > [  138.545525] x15: 093c8c08 x14: 6c756e2820202020 
> > [  138.546511] x13: 202020202020206f x12: 7420646574636574 
> > [  138.547489] x11: 093c9658 x10: 086ae800 
> > [  138.548466] x9 : 7265766f2079726f x8 : 0017 
> > [  138.549445] x7 : 6c756e3c2820296c x6 : 8003eeb51c28 
> > [  138.550434] x5 : 8003eeb51c28 x4 :  
> > [  138.551411] x3 : 8003eeb59ec8 x2 : d4a0cd0f45236000 
> > [  138.552388] x1 :  x0 : 0059 
> > [  138.553364] Process dmraid (pid: 2271, stack limit = 0x110e8000)
> > [  138.554593] Call trace:
> > [  138.555043] Exception stack(0x110eb9c0 to 0x110ebb00)
> > [  138.556214] b9c0: 0059  d4a0cd0f45236000 
> > 8003eeb59ec8
> > [  138.557653] b9e0:  8003eeb51c28 8003eeb51c28 
> > 6c756e3c2820296c
> > [  138.559082] ba00: 0017 7265766f2079726f 086ae800 
> > 093c9658
> > [  138.560510] ba20: 7420646574636574 202020202020206f 6c756e2820202020 
> > 093c8c08
> > [  138.561950] ba40: 082dd3b0 83380ce0  
> > 
> > [  138.563379] ba60: 0006  0006 
> > 0006
> > [  138.564805] ba80: 8003e1131920 0802001d 8003e8d3d800 
> > d88e1110
> > [  138.566238] baa0:  110ebb00 082c0e5c 
> > 110ebb00
> > [  138.567666] bac0: 082c0e5c 00400145 08e25a80 
> > 
> > [  138.569090] bae0: 0001 0006 110ebb00 
> > 082c0e5c
> > [  138.570523] [] __check_object_size+0x114/0x200
> > [  138.571628] [] sg_io+0x120/0x438
> > [  138.572507] [] scsi_cmd_ioctl+0x594/0x728
> > [  138.573531] [] scsi_cmd_blk_ioctl+0x50/0x60
> > [  138.574594] [] virtblk_ioctl+0x60/0x80 [virtio_blk]
> > [  138.575769] [] blkdev_ioctl+0x5e4/0xb50
> > [  138.576756] [] block_ioctl+0x50/0x68
> > [  138.577698] [] do_vfs_ioctl+0xc4/0x940
> > [  138.578671] [] SyS_ioctl+0x8c/0xa8
> > [  138.579581] Exception stack(0x110ebec0 to 0x110ec000)
> > [  138.580752] bec0: 0005 2285 d88e10b8 
> > 0006
> > [  138.582199] bee0: